RudderStack MCP

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety and openness profile is covered structurally. The description adds genuinely useful behavior context by promising source citations in the answer. It does not explain non-determinism, latency, or how follow-up threads behave, which is where the added value would have been greatest given idempotentHint=false.

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 capability front-loaded and the usage imperative second. No filler, though the all-caps ALWAYS reads as a directive rather than descriptive guidance and slightly weakens the professional tone.

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-only, no-output-schema tool, the description covers what it returns at a high level (answers plus citations). It remains incomplete on the required query parameter's semantics, the follow-up thread workflow, and how it relates to search_docs, all of which an agent needs to call it well.

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 only 50%: thread_id is documented in the schema, but query has no description at all. The description says nothing about either parameter, so it fails to compensate for the undocumented required query field or explain that thread_id enables conversational follow-ups. This is a real gap for a required-parameter tool.

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: retrieving AI-generated answers from RudderStack documentation, with the notable qualifier that answers include source citations. This clearly distinguishes it as a synthesized-answer tool rather than a raw lookup, but it never names the closely related sibling search_docs, so the agent must infer the boundary itself.

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 an explicit, forceful when-to-use rule: call it before answering RudderStack questions. That is strong positive guidance. It stops short of a 5 because it offers no when-not condition and no routing advice relative to search_docs, which occupies overlapping territory.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds nothing beyond the workspace scope — no mention of pagination defaults, ordering (newest first?), or how target/target_type filtering behaves.

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 filler, which is structurally clean. It is arguably too terse for a five-parameter tool, but no wording 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?

For a paginated read tool with five parameters, a 40% schema coverage gap and no output schema, the description should explain the filter semantics and result ordering. As written, an agent must guess how target/target_type combine and what the returned log entries look like.

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 only 40%: skip and limit are documented in the schema, but target, target_type (a 15-value enum) and workspace_id have no descriptions anywhere. The one-line description does nothing to compensate, leaving the meaning of the filter pair and the enum values unexplained.

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 ("Lists audit logs") and scopes it to a workspace, so an agent knows exactly what the tool returns. It does not differentiate from siblings, though none of the listed siblings appear to be audit-log tools, so the risk of confusion is low.

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 word "Lists" and the workspace scoping; there is no explicit statement of when to reach for this tool versus things like get_workspace_settings or the list_* siblings. No exclusions or prerequisites are mentioned.

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?

The annotations already declare destructiveHint=true and idempotentHint=true, and the description earns credit by explaining what those mean concretely: the sync mirrors membership so people not in the audience are removed from the destination, and a repeat call returns status 'skipped' which counts as success. It also notes the connection result is returned. It does not cover permission requirements or failure modes beyond the already-connected case.

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?

Front-loaded with what the tool does, then prerequisite, then required inputs, then behavioral notes, then return semantics — a sensible order. A few clauses duplicate what the schema already says (the schedule enum, the parameter inventory), which is the only waste.

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, idempotent mutation with no output schema, the description covers purpose, prerequisite call, required inputs, cadence, the membership-mirroring side effect, and the success-shaped 'skipped' response. Nothing an agent needs before invoking it 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 83%, so the schema already carries most of the parameter meaning, including the full enum semantics for schedule and the mappingGuidance/fk-check guidance for audience_id_on_destination and identifier_mappings. The description mostly restates the required-parameter list and the hourly/daily/manual enum, adding little 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?

States a specific verb and resource ('Creates a connection between an existing ... audience and an activation-capable destination') and pins the scope to Data Graph audiences, which cleanly separates it from connect_transformation_destination and the read-only get_/list_ 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?

'Call get_audience_destination_schema first' gives an explicit prerequisite ordering, and the required inputs (audience ID, destination ID, destination-side audience ID, identifier mappings) describe the preconditions for a valid call. It stops short of naming an alternative tool or a when-not-to-use condition, so it is clear context rather than full routing 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?

Annotations already declare readOnlyHint=false and idempotentHint=true, and 'prevents duplicates if already connected' restates idempotency in practical terms. It adds nothing about permissions, what happens to an existing link (error vs. no-op), or whether the transformation must be published before linking.

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, front-loaded with the action and effect, with no filler. The second sentence is slightly redundant with the idempotent annotation but is still useful to an agent reading only the description.

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 output schema, the description should say what a successful call returns and what happens on an already-linked pair. It hints at the duplicate case but omits the return shape and the one undocumented parameter, so it is adequate rather than 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?

At 67% schema coverage, transformation_id and destination_id already carry 'ID from list_*' hints in the schema, and the description adds no further meaning. workspace_id is undocumented in both the schema and the description, leaving a real 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?

States a specific verb and resource ('Link transformation to destination') plus the effect on event processing, which is clearly distinct from connect_audience_destination. It does not explicitly name the sibling it differs from, so it stops 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?

No when-to-use guidance, no prerequisites (existing transformation and destination IDs, workspace scope), and no comparison to connect_audience_destination. The only conditional information is the duplicate-prevention note, which is about behavior rather than when to call the tool.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the agent knows this is a non-idempotent, non-destructive write. The description adds genuinely new behavioral context in the mandatory skill-load prerequisite, which annotations cannot convey. However, it says nothing about what is returned, whether duplicate names are rejected, or permission requirements, so it adds only partial context beyond annotations.

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, with the mandatory prerequisite front-loaded where the agent will see it. Nothing could be removed without losing information.

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?

There is no output schema, so the agent has no way to learn what a successful creation returns — critically, whether an audience id comes back for use with get_audience or preview_audience. The nested `where` predicate object is opaque and the description does not explain that it is validated or how failures surface. The skill prerequisite is covered, but the post-creation story is not.

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 83%, so the schema already documents `from`, `name`, and `where` in detail. The description contributes no parameter-level meaning beyond the resource name; the `where` predicate's dependency on the loaded skill is already stated in the schema itself. 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 and resource: 'Creates a RudderStack Data Graph audience.' An agent can distinguish this from update_audience and preview_audience by the verb alone. It does not explicitly contrast itself with those siblings, so it stops 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?

Gives an explicit prerequisite ordering — 'MUST call `load_audience_skill` first' — and names the sibling to call first, which is the single most important routing decision for this tool. It gives no guidance on when to prefer preview_audience before creating or when update_audience is the right alternative, so it lacks 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?

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds useful behavior beyond that: what fields come back and the prerequisite skill call before mutation, though it omits error behavior for a bad id or cross-workspace mismatch.

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, front-loaded with the return payload and followed by the one workflow constraint. No redundant restatement of the name or title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description helpfully lists the returned fields, which is exactly what's needed for a get-by-id tool. The main gap is the undocumented workspace_id, which leaves an agent guessing about scoping.

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 only 50%: audience_id is well documented with provenance (create_audience, peerAudiences), but workspace_id has no description anywhere. The description's 'by id' adds nothing about either parameter and does not compensate for the undocumented workspace scoping.

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 (returns an audience by id) and goes further by enumerating the returned payload fields (config.expression, name, description, tags, audit fields). It does not explicitly differentiate itself from get_audience_model_context or preview_audience, which keeps it below 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?

Gives an explicit conditional workflow: call load_audience_skill first when the intent is to modify the returned expression. It does not explain when to prefer this over get_audience_model_context or preview_audience, so alternative routing is only partially covered.

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?

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds value beyond them by disclosing the response payload keys and the prerequisite sequencing relative to connect_audience_destination. It stops short of describing size/pagination of the audiences list or what happens for a non-activation destination.

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, front-loaded with purpose, then return shape, then the routing instruction. No filler, no restatement of the title, and the most decision-relevant clause (use before connect_audience_destination) closes the description.

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, the description helpfully enumerates the returned keys (fields, audiences, mappingGuidance) and the prerequisite workflow, which is enough for an agent to call it correctly. Minor gap: the shape of each returned item and the fact that workspace_id is required-but-unexplained are 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 coverage is 50%: destination_id is well documented in the schema (ID from list_destinations, must be activation_capable), but the description adds no meaning to it. workspace_id is undocumented in both places and the description does not compensate, so this sits at the baseline rather than above 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 ('Discover') and precise resource pair ('destination-side identifier fields and existing audiences') constrained to activation-capable destinations. It is clearly distinguishable from get_destination and get_destination_definitions, and the return shape is named up front.

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 prescribes ordering: 'Use this before connect_audience_destination', and tells the agent why (to pick the destination-side audience and valid mapping targets). It does not name a when-not case or an alternative discovery tool, but the activation-capable qualifier implicitly bounds usage.

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?

Annotations already cover read-only, idempotent, non-destructive, closed-world. The description adds real behavioral context beyond them: the 2-hop relationship.path cap, the fact that root models additionally return peer audiences composable via the audience predicate, and the distinction between path (warehouse column) and legacy label. It stops short of describing result shape or size limits when a model has many neighbors.

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 core capability and the iterative call pattern are front-loaded, followed by attribute semantics and the hop-cap constraint. Every sentence carries information, though the displayName/description/piiMask sentence is dense and could be tightened.

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, the description does the work of explaining what comes back: attributes, neighbor attributes, relationship metadata, peer audiences for roots, and optional metadata fields. Remaining gaps are minor for a two-parameter read tool — notably the meaning of workspace_id and any guidance on large neighbor sets.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: model_id is documented in the schema, workspace_id is not. The description meaningfully extends model_id by tying it to the iterative 2-hop walk and clarifying it accepts any model, root or not, but it says nothing about workspace_id, leaving half the parameters unilluminated.

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: returns model attributes plus 1-hop reachable neighbors with relationship metadata, for any model in the data graph, root or not. That scope statement distinguishes it from list_audience_subjects and get_audience, though it never names a 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?

It gives a concrete procedure: call first with the chosen subject, then iterate using a 1-hop neighbor's modelId to reach 2 hops, and it notes the backend caps relationship.path at 2 hops. It does not state when to prefer this over list_audience_subjects or how it relates to preview_audience, so alternatives are implied rather than 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's added value is the return-content inventory, which matters given there is no output schema, but it says nothing about auth/plan-tier requirements, error behavior for unknown workspace IDs, or whether values are real-time or cached.

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 front-loaded sentence with no filler. The unusual unit note ('in millions') is placed inline where it is needed rather than as a trailing caveat.

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 single-parameter read tool the description covers purpose and return contents reasonably well, which is important with no output schema. It falls short on the one required input (workspace_id format/provenance) and on any indication of what happens on failure or for tenants without contracts.

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 0% for the single required parameter workspace_id, so the description carries the full burden. 'For the workspace' only loosely implies the ID's role; it gives no format, source, or how to obtain the ID, leaving the only parameter effectively undocumented.

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?

Uses a specific verb ('Get') and a specific resource ('billing/tenant information for the workspace') and enumerates the returned fields (contract event volume in millions, plan name, org name, owner email). This is enough to distinguish it from a generic sibling such as get_workspace_settings, though it never explicitly contrasts with that sibling.

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: an agent can infer this is the tool for billing/plan/contract questions from the enumerated fields. There is no explicit 'use this when' framing, no exclusions (e.g. vs get_workspace_settings or user_details), and no mention of prerequisites or permissions.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the useful fact that the response bundles configuration, sources and transformations - relevant since there is no output schema - but says nothing about permissions, rate limits, or how deeply those sub-objects are returned.

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 that identifies the resource and immediately enumerates the payload contents. Zero 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 read tool with full annotations, the description covers purpose and return contents adequately. It leaves gaps on the undocumented workspace_id and on how to choose this over the many sibling destination 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 coverage is only 50%, and the one documented parameter (destination_id, sourced from list_destinations output) is documented in the schema itself, not the description. workspace_id has no description anywhere, and the tool description adds no meaning about either parameter.

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 ('Get complete destination details') and enumerates what is included: configuration, connected sources and transformations. That distinguishes it from list_destinations or get_destination_definitions by content, though it never names a 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?

Usage is only implied: 'complete details' suggests fetching a single destination after listing, and the destination_id description points back to list_destinations. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. get_destination_event_metrics for metrics).

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds no behavior beyond that: it says nothing about the fact that returning config schemas requires filters (a constraint buried only in the schema), nor about result size, pagination, or scoping by workspace.

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 wasted wording; the content nouns are compact and scannable. It is efficient but so terse that it omits constraints that would have earned the space.

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 read-only metadata lookup with rich annotations and a moderately documented four-parameter schema, the essentials are covered elsewhere. However, the description omits the notable conditional rule that includeConfig=true requires an id or name filter, which is the most likely source of a failed 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?

With 75% schema description coverage the schema already documents includeConfig's filter requirement and the comma-separated id/name filters, so the baseline is 3. The description contributes no parameter meaning at all, leaving workspace_id undocumented in both places and the naming/id filter distinction solely to 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 names a specific verb and resource ('Get destination definition metadata') and enumerates the content returned ('configuration schemas and capabilities'). It does not differentiate itself from nearby siblings such as get_destination, get_source_definitions, or get_audience_destination_schema, so an agent must infer the distinction 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?

Usage is only implied: a caller infers this tool is for inspecting destination-type metadata and capabilities, presumably before connecting a destination. There is no explicit statement of when to use it, when not to, or which sibling to prefer for connection-level versus definition-level 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description does add some return-shape context — that filteredEvents enumerates all filtered events in the window and that events rows carry filteredCount — but it never describes pagination behavior, aggregation granularity, or the overall response structure, which matters since no output schema exists.

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 before the return-detail caveat. The second sentence is compressed into semicolon-separated clauses and uses bare field names (filteredEvents, filteredCount) without framing, which makes it slightly harder to parse than it needs to be.

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 7-parameter read-only metrics tool with no output schema, the description covers purpose and two response fields but leaves the time-window semantics, pagination, and the full metric set unexplained. Annotations carry the safety story, but an agent still lacks enough to predict what it will get back.

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 71%, with start_time, failures_only, page_size, page_number, and destination_id already documented in the schema. The description adds nothing about event_type (undocumented in both places) or how page_size/page_number interact with the two enumerated result sets, so it does not compensate for the 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 names a specific verb and resource ('Get destination event-delivery metrics') and scopes it to success/failure rates, which distinguishes it from the source- and transformation-level metric siblings by the word 'destination'. It stops short of explicitly naming the nearest alternatives such as get_destination_latency_metrics or get_destinations_errors.

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 pick this tool over get_destination_latency_metrics, get_destinations_errors, or get_live_events, and no prerequisites are given. Usage is only inferable from the tool name and the resource it mentions.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the vague phrase 'over time' and says nothing about what the series contains (percentiles vs. averages), how granularity interacts with the requested range, retention limits, or behavior when no data exists in the window.

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 with the verb and resource and contains zero filler. It is not padded, though its brevity is closer to under-specification than to disciplined concision given the tool's five required parameters.

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 five-parameter, all-required time-series query tool with no output schema, so the description must carry the burden of explaining the shape of the returned metrics and the step/range interaction. It says none of that, leaving an agent unable to predict the response or choose sensible start/end/step values.

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 80%, so start/end/step/destination_id are already documented in the schema, and the description adds no extra semantics such as step alignment rules or maximum range constraints. The undocumented workspace_id parameter remains unexplained beyond its name, which the description does nothing to compensate for.

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 resource (destination latency metrics) and a scope (over time), which is more than a pure tautology, but it essentially restates the tool name and title verbatim. It draws no boundary against siblings like get_destination_event_metrics or get_transformation_latency_metrics, so an agent must infer which metrics tool to pick.

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 at all: no mention of when latency rather than event metrics is the right call, no prerequisites (destination must be connected), and no statement about alternatives among the many sibling metrics tools. The agent is left to guess 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the meaningful detail that PII is hashed, which tells the agent the output is sanitized. It does not disclose the default 24-hour window, the 10-destination cap, or the shape/cost of sample retrieval, all of which affect 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 sentences, front-loaded with the verb and resource, with the PII note trailing as a useful qualifier. No filler, though the second sentence is terse to the point of being a fragment.

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 six parameters and no output schema, the description leaves the return shape entirely unexplained — an agent does not know whether results are grouped per destination, what 'error details' contain, or how samples are structured. For a diagnostic tool of this size that is a notable gap, though annotations and a well-documented schema cover the call mechanics.

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 83%, so parameter meaning is largely handled by the schema. The description's mention of 'optional sample events and error details' loosely maps to include_sample_events and include_sample_response but adds no syntax, defaults, or interaction 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?

States a specific verb and resource: retrieving destination delivery failures. This is distinguishable from get_destination (configuration) and get_destination_event_metrics (metrics), though the description never names those siblings 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?

Usage is only implied — an agent can infer this is for diagnosing delivery failures — but there is no explicit when-to-use statement, no prerequisite (e.g., destination_ids must come from list_destinations, which is only noted in the schema), and no guidance on choosing it over get_destination_event_metrics or get_destination_latency_metrics.

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?

The description adds a genuine behavioral note not present in structured fields: PII is hashed for privacy, which tells the agent return values are masked. However, it omits the most consequential behavior — that this is a long-poll that blocks until events arrive or the wait window expires — and does not explain why readOnlyHint is false for a "get" 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?

Two short sentences with the core purpose front-loaded and no wasted wording. The trade-off is that the brevity comes at the cost of under-specification rather than through efficient information density.

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 nine parameters, two enums, no output schema, and streaming/long-poll semantics, the description is far too thin. It never explains what one call returns, how wait_for_events and max_wait_seconds shape the response, or that the call can block for up to 120 seconds.

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 67%, so the schema already documents most parameters, giving a baseline of 3. The description adds a small amount by framing the tool as spanning sources, destinations, and transformations, which motivates the three respective ID filters, but it adds no detail on event_name, event_type, or filtering semantics.

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 real-time events, scoped across sources, destinations, and transformations. This distinguishes it reasonably from metric-oriented siblings like get_destination_event_metrics, but it never explicitly names when to prefer it or why it differs from other event-listing 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 when-to-use guidance, no prerequisites, and no named alternatives among the many sibling tools. The only implied usage comes from the parameter names, leaving the agent to infer that this is a live-tail/polling call rather than a historical query.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered by structured data. The description adds the useful fact that the tool has two distinct behaviors (listing versus file retrieval), but says nothing about pagination, result limits, or what happens on a missing path.

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 two modes are joined compactly and nothing is repeated from the schema.

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 three-parameter read tool with full annotation coverage and no output schema, this is minimally adequate. It omits what the listing contains and how artefact content is returned, which an agent would want before choosing between the two 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 67% and the key discriminator (relative_path empty lists, non-empty fetches) is already documented in the schema. The description reinforces the task-scoped nature but adds no format, path-syntax, or workspace_id meaning 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 ("List profile task artefacts") plus a second mode ("fetch artefact file content for a specific task"). An agent can tell what it returns, though the description never distinguishes this tool from near-siblings like get_profile_details or list_profiles.

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 dual-mode behavior hints at when each mode applies, but the actual condition (empty vs non-empty relative_path) is only spelled out in the schema, not the description. There is no explicit when-to-use or when-not-to-use guidance relative to alternatives.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description usefully signals that the response varies by detail_type, which is real behavioral information, but says nothing about payload differences, pagination, or that only history supports time filtering.

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 filler. The only redundancy is that the enumerated detail types duplicate the schema's enum, which could have been spent on payload or usage detail instead.

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 a tool that returns four materially different payload shapes, the description should explain what each detail type yields and what the history time filters do. Five parameters and three required fields are handled entirely by the schema, leaving the agent to guess the return structure.

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 80%, so the schema already documents profile_id, detail_type, and the history timestamps; the description merely restates the detail_type enum. It adds no meaning for workspace_id or an explanation of how started_after/started_before interact with the history detail type.

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 profile details") and enumerates the four detail types the tool exposes, so an agent knows what it retrieves. It stops short of distinguishing itself from close siblings such as get_profile_artifacts or list_profiles, so it is clear but not fully disambiguating.

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: nothing says when to pick one detail_type over another, when to call this instead of get_profile_artifacts, or that profile_id must first come from list_profiles (that hint lives in the schema, not the description). The enum listing implies selectable modes but gives no selection criteria.

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?

Beyond the annotations it discloses the full behavioral surface: warehouse compute is billed to the customer, error_message may contain customer data, the 5000-record reachability cap, truncation at 500 chars unless full_messages is set, and every non-'ok' status (error_details_off, not_retained, not_captured, warehouse_config_changed, running) with recovery behavior. The 'changes no data but bills compute' note also explains why readOnlyHint is false without contradicting 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?

Front-loaded with what gets returned, then sourcing, then filtering/pagination, then risk and status semantics — a sensible order for a 9-parameter tool. Some resume_id instructions are restated from the schema, and the parenthetical status list makes it dense, but no sentence is 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 tool with nine parameters, no output schema, and a branching status model, the description supplies the return shape, the failure modes, the sensitivity and cost caveats, and the retry protocol. An agent has everything needed to call it and to interpret a non-'ok' response without guessing.

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 89%, so the schema already carries most parameter meaning; the description's added value is the 5000-record window constraint, which tells the agent that error_code/search are the escape hatch rather than paging alone. It does not add anything for workspace_id or full_messages beyond what the schema 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 opening sentence names a specific verb and resource ('Read one page of a finished Reverse ETL sync run's FAILED records'), scopes it to a single page and run, and enumerates the returned fields (_rudder_id, primary_key, operation, error_code, error_message). This clearly separates it from get_retl_source_syncs (which yields run ids) and get_destinations_errors.

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 explicitly routes the agent to list_connections for connection_id and get_retl_source_syncs for run_id, and explains the filter-versus-page tradeoff when a run exceeds 5000 records. It stops short of an explicit 'do not use this tool when…' exclusion against the error-listing siblings, but the surrounding context is strong.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that results carry metrics and timing, but says nothing about result volume, pagination, ordering, or what happens with a large time window.

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 sentence, front-loaded with the operation and resource, with zero filler. It is arguably too terse rather than bloated, which is the right failure mode for this dimension.

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 six-parameter, filter-driven read tool with no output schema, the description conveys the return content at a high level but omits filtering behavior, default 24-hour windowing implications on result size, and pagination. Annotations cover the safety side, so the remaining gap is moderate rather than severe.

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 67%, with source_id, destination_id, and time bounds documented in the schema and the status enum self-explanatory. The description adds nothing about how these filters combine (e.g., that status filters the execution list or that destination_id narrows to a specific connection), so it neither compensates for nor worsens the partial 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?

States a specific verb ('Get') and resource ('RETL sync execution results') and adds what the payload contains (metrics and timing). That is enough to distinguish it from list_sources or get_retl_failed_records at a glance, though it does not explicitly name a sibling.

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 when to prefer get_retl_failed_records, and no prerequisite noted even though source_id and destination_id come from list_sources and list_destinations. The agent must infer all usage 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety and repeatability are covered. The description adds useful scope information by naming the returned sections, but says nothing about whether the response is bulky, whether tracking plans are summaries or full versions, or about failure modes for an invalid source_id.

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 compact sentence that front-loads the verb and the payload enumeration; nothing is redundant. It is slightly terse to the point of being a fragment, but no words are 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 output schema, the description is the only place the return contents are conveyed — and it does name them, which is its main contribution. However, for a tool with two required params and a partly undocumented workspace_id, it leaves gaps an agent must resolve by 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 coverage is only 50%: source_id is documented in the schema ('Source ID from list_sources output') while workspace_id carries no description anywhere. The description adds no parameter meaning at all, so it fails to compensate for the undocumented required parameter.

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?

Uses a specific verb and resource ('Get ... source details') and enumerates the payload shape: configuration, tracking plans, connected destinations. That distinguishes it from list_sources and metric-oriented siblings, though it never names the closest alternative (get_source_tracking_plans_and_versions) to resolve the apparent overlap over tracking-plan content.

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?

Retrieval-for-a-known-ID usage is implied by 'Get ... details' and the required source_id, but there is no explicit when-to-use or when-not guidance against siblings such as get_source_definitions or get_source_tracking_plans_and_versions. The agent has to infer the routing itself.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered and the bar for credit is lower. The description adds nothing beyond them: it does not mention that includeConfig=true imposes a mandatory filter dependency, nor anything about response volume, pagination, or what "capabilities" actually contains.

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. It is efficient, though the brevity borders on 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?

With no output schema, the description carries the burden of explaining what is returned, yet "configuration schemas and capabilities" is too abstract to tell an agent what fields or objects come back. For a two-required-parameter read tool with a conditional dependency, it leaves meaningful gaps about both selection and results.

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 75%, with the conditional includeConfig constraint and both filter parameters already documented in the schema. The description contributes no additional meaning about the required workspace_id scope or how the id/name filters behave, so the schema is doing essentially all the work.

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 source definition metadata") and adds scope in "configuration schemas and capabilities." However, it does nothing to distinguish this from siblings such as get_source, list_sources, or the analogous get_destination_definitions, so an agent cannot tell which catalog-vs-instance tool to pick from the text 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 when-to-use guidance, no exclusions, and no reference to any alternative tool. The agent is left to infer from the name whether this returns a catalog of source types or definitions of already-configured sources in the workspace.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add return-shape context. It does add some: filteredEvents lists every event a destination filter dropped in the window, and events rows carry filteredCount. That is genuinely useful, but it is stated so tersely that the agent cannot tell the response structure or how the two collections relate.

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 with the purpose front-loaded, so no padding. However, the second sentence crams two output-field names (filteredEvents, filteredCount) into one clause without enough context to be parseable on a first read.

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 8-parameter metrics tool with no output schema, the definition is only partly adequate. It hints at the return payload but does not describe aggregation window behavior, pagination, or what the counts represent, leaving real gaps for an agent composing a query.

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?

Eight parameters with 63% schema coverage, and the description explains none of them. sort_by, sort_order and workspace_id are undocumented anywhere, and start_time/end_time are only obliquely gestured at via 'in the window' without stating the default 2-hour lookback or RFC3339 format. It adds essentially no meaning 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?

"Get source event-volume metrics including counts by event type/name" states a specific verb (get), resource (source event metrics), and what the payload contains. The 'source' qualifier separates it in spirit from get_destination_event_metrics and get_transformation_event_metrics, though those siblings are never named.

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 or when-not-to-use guidance and no alternative is named. An agent must infer from the name alone whether this or get_source_tracking_plan_event_metrics / get_source_event_properties is the right tool for a given question.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only the 'similarity scoring' mechanism, saying nothing about what is returned (e.g., scored pairs) or how the threshold interacts with results -- and no output schema exists to compensate.

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 compact sentence with the action and scope front-loaded and no filler. It is efficient, though it leaves room for one clarifying clause about the output without becoming bloated.

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-parameter read-only tool with no output schema, the definition covers the core intent but omits the return shape -- the name suggests scored name pairs, yet neither description nor structured fields confirm this. Adequate but with a clear gap for an agent deciding whether the result fits its need.

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 75%, with limit and similarity_threshold documented inline and only workspace_id bare. The description's mention of 'similarity scoring' loosely ties to the threshold parameter but adds no format or behavior detail beyond the schema; baseline 3 is appropriate for a mostly self-documenting 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 and resource -- finding similar or duplicate event names within a source -- and names the mechanism (similarity scoring). It is distinguishable from siblings like get_source_event_schemas or get_source_event_properties, though it never explicitly contrasts 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The purpose (detecting duplicate/similar event names) implies a deduplication use case, but an agent must infer the scenario on its own.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results include property types and frequency, which is modest but genuine context beyond annotations; it says nothing about pagination or how frequency is computed.

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 key verb and resource front-loaded and no filler wording. It is efficient, though it sacrifices detail for brevity.

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 exists, and with 5 parameters (3 required) and only 60% schema coverage, the description is thinner than ideal. It gives a rough sense of the return content but leaves required-parameter intent and filtering behavior 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 60%, and the description adds no parameter-level meaning beyond the vague 'specific event' phrasing. It does not clarify event_name scoping, workspace_id, the limit default, or the property_type filter options ('all', 'common', 'non_common').

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 ('property metadata for a specific event') plus what the payload includes (types and frequency). It does not distinguish itself from close siblings such as get_source_event_schemas, get_source_event_names_similarity, or list_data_catalog_properties, so an agent must infer the difference.

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 explicit when-to-use or when-not-to-use guidance and no mention of alternatives. Usage is only implied by the phrase 'specific event', leaving the agent to guess how this differs from the other event/property 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?

Annotations already declare readOnly/idempotent/non-destructive, so the description earns credit for disclosing the pagination model ('Returns 10 events per page') and the exact columns per row, which the annotations cannot express. It does not state ordering, total counts, or whether 'first/last seen' is bounded by a time window.

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: the first front-loads what the tool returns and its row granularity, the second gives pagination size and the alternative for a related need. No filler or repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, describing the returned columns is essential and is done well, and pagination size is a valuable addition. The remaining gap is minor but real: no indication of result ordering or how to know when paging is finished.

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 67% with 'page' described only as 'Page number' and workspace_id undocumented. The description's '10 events per page' meaningfully helps interpret the page parameter, but it says nothing about workspace_id or whether page is 1-indexed or has a terminal condition.

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?

Uses a specific verb and resource ('Lists the event schemas seen on a source') and immediately defines the row shape (event type, name, first/last seen, count), which distinguishes it clearly from get_source_event_properties, get_source_event_metrics, and get_source_event_names_similarity.

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 routes the agent to get_source_event_properties when properties/types are needed, which is the main ambiguity for this family of tools. It gives no guidance about when to prefer get_source_event_metrics or how to page through results to completion, so it stops short of full when/what-alternative coverage.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only that results include violation statistics; it says nothing about time-window behavior, pagination, or result volume beyond what the schema hints at.

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, front-loaded sentence with no filler, which satisfies conciseness. However, the brevity reflects under-specification rather than efficient communication, since the sentence could have carried scoping or parameter context at trivial length cost.

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 7-parameter, 4-required tool with no output schema and partial schema coverage, the description is far too thin. It does not explain the required workspace_id/tracking_plan_id relationship, the default time window, or what the metric payload looks like.

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 57% and the description mentions no parameters at all. The schema documents page, page_size, start and source_id, but workspace_id, tracking_plan_id and tracking_plan_version have no explanation anywhere, and the description does nothing to compensate for that 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 names a specific verb ('Get') and a precise resource ('tracking plan event validation metrics') and adds that violation statistics are included. It is clear what the tool returns in kind, but it never distinguishes itself from close siblings like get_source_tracking_plan_event_violations, get_source_event_metrics, or get_source_tracking_plans_and_versions.

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 or when-not-to-use guidance, and no alternative is named. An agent must guess whether this or get_source_tracking_plan_event_violations is the right call for validation 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds one genuinely new behavioral fact: PII in returned data is hashed. It does not cover the default two-hour time window, sample limits, or result shape, which matters for a read with no output 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?

Two short sentences with no filler, and the core capability is front-loaded. It is arguably too terse for a 10-parameter tool, but 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 10-parameter tool with no output schema, the description leaves major gaps: how source_id relates to tracking_plan_id/tracking_plan_version, what the default time window is, and what the sample-event flags return. An agent must read the entire schema to call it 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 70%, and the schema already documents start, event_name/event_type pairing, max_samples, and the sample flags. The description only echoes 'optional sample events' and adds that samples are hashed; it says nothing about workspace_id, tracking_plan_id, or tracking_plan_version semantics.

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: retrieving tracking plan validation failures with violation details. It implicitly distinguishes itself from the metrics sibling by focusing on 'validation failures' rather than metrics, but it does not name that sibling or otherwise explicitly differentiate.

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_source_tracking_plan_event_metrics, list_tracking_plan_events, or get_source_event_schemas. Prerequisites, like whether tracking_plan_id or tracking_plan_version must be supplied even though they are not marked required, are not addressed.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that: it does not explain what "associations" are, whether results are time-windowed by the start parameter's default, or how results are ordered or paginated.

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, front-loaded sentence with no filler or redundancy. It is efficient, though its brevity stems from under-specification rather than disciplined editing.

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, the description should convey what comes back, and "associations and versions" leaves the return shape ambiguous. The read-only nature and the time-window parameter are handled by annotations and schema, so the tool is callable, but an agent cannot predict the payload.

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 67%: start documents its RFC3339 format and 2-hour default, and source_id points at list_sources, but workspace_id has no description anywhere. The tool description contributes no parameter meaning at all, so it does not compensate for the workspace_id 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 has a verb+resource shape ("Get tracking plan associations and versions for a source"), but the resource is fuzzy: "associations" is undefined and "versions" could mean tracking plan versions, schema versions, or source versions. It does not distinguish this tool from nearby siblings such as get_source_tracking_plan_event_metrics, get_source_event_schemas, or list_tracking_plans.

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 prerequisites, and no named alternative. An agent cannot tell from this sentence whether to call this tool or list_tracking_plans / get_source when it wants tracking plan information for a source.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered without the description. The description adds that the response includes all updates and affected components, which is useful given there is no output schema, but says nothing about behavior for unknown/invalid incident IDs or any rate limiting.

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 front-loaded sentence with no filler; the payload contents are appended after the core action, which is the right ordering. Nothing could be removed without losing information.

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, the description covers purpose and what the response contains, which is the main gap it needed to fill. The only missing piece is how to obtain a valid incident_id and what happens on a missing incident.

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 carries its own description ('The incident ID to retrieve details for'), so the schema does the heavy lifting. The description adds no format, source, or example detail for incident_id beyond what is already structured.

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 ('status page incident') with scope qualifiers ('a specific', as opposed to a list), so it is distinguishable from list_statuspage_incidents. It does not explicitly name the sibling, but the singular/plural contrast is clear enough.

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: 'a specific incident' suggests the agent must already have an identifier, which in practice comes from list_statuspage_incidents, but the description never says so. There is no explicit when-to-use, when-not-to-use, or prerequisite 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description usefully adds that the response includes source code and configuration, but says nothing about permissions, workspace scoping, or error behavior when the ID is unknown.

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 wasted words. It is efficient, though the terseness leaves little room for routing or scoping guidance.

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-only getter with no output schema, the description covers the headline (source code and configuration) but omits workspace scoping and any indication of response shape or failure modes. Adequate but with clear gaps.

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 only 50%: transformation_id is documented as 'ID from list_transformations' but workspace_id has no description at all. The description adds no meaning about either parameter, so it fails to compensate for the 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?

States a specific verb ('Get') and resource ('transformation details'), and adds scope beyond the name by naming what is returned: source code and configuration. The singular 'get' plus the ID parameter distinguishes it from list_transformations, though it does not explicitly name the sibling.

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 explicit guidance on when to use this versus alternatives such as sample_transformations, get_transformation_library, or transformation_test_existing. Usage is only weakly implied by 'complete ... details'; an agent must infer that this is the fetch-by-ID tool.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety, and idempotency are covered. The description adds that the result is a time series broken down by success/failure and error type, which is useful behavior beyond annotations. It omits whether the window extends to 'now' (there is no end parameter), any row cap, or pagination 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 front-loaded sentence with no filler; the returned metric categories are stated up front. It is efficient but leaves no room for the scoping details an agent would want.

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, the description carries the burden of describing the return value, and it does so only at a high level (volume, rates, errors over time). It never explains that the time range is bounded only by 'start' (implicitly to now) nor how granularity bucketing affects the response, which matters for a 4-required-parameter metrics 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 75%, so the schema already explains start (RFC3339), granularity_in_minutes, and transformation_id (via list_transformations); only workspace_id lacks a description. The description adds no extra parameter meaning, such as how granularity shapes the returned buckets or why no end time is accepted. Baseline 3 is appropriate when the schema carries most of the load.

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 plus resource ('Get transformation event metrics') and enumerates the payload dimensions (volume, success/failure rates, errors over time). It does not distinguish itself from the closely related siblings get_transformation_latency_metrics, get_destination_event_metrics, or get_source_event_metrics.

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 or when-not-to-use guidance, no prerequisites, and no mention of the alternative metrics tools in the sibling list. An agent must infer from the name alone whether this is the right metrics endpoint for failure analysis versus latency analysis.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that – no note on whether the series starts at 'start' with no end bound, whether empty buckets are returned, or how granularity affects the result, which are the behaviors an agent would actually need.

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 front-loaded sentence with no filler, which is structurally clean. However, the brevity comes from under-specification rather than efficiency – one clause of scope is all that exists for a tool with four required parameters and a time-series output.

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 four required parameters, an enum granularity, and no output schema, the description should carry real weight about the returned time series and the meaning of the time window. Instead it supplies nothing about return shape, units of latency, or the absence of an end-time parameter, which is a notable gap for a metrics tool.

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 75%, with the enum for 'step', the RFC3339 format for 'start', and the provenance of 'transformation_id' already documented in the schema itself. The description adds no meaning on top of that and says nothing about the undocumented 'workspace_id' or whether 'start' is the only time bound, so the baseline of 3 is warranted.

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 verb and resource (get latency metrics) and adds a scope cue ('over time'), so the general intent is graspable. But it is nearly a restatement of the tool name and never distinguishes this from close siblings such as get_transformation_event_metrics or get_destination_latency_metrics, leaving the agent to infer what makes latency metrics different.

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 at all: no mention of when to prefer this over get_transformation_event_metrics, no prerequisite that the transformation must exist, and no note about what time window is appropriate. The only routing hint in the whole definition lives in the schema ('ID from list_transformations'), not the description.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: the response includes source code, which signals potentially large or sensitive payloads. It does not say what happens when the library has no source, nor whether the call is expensive.

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 wasted words, and the most useful detail (source code included) is placed where it is read first. It is arguably too terse for the gaps it leaves, but there is no filler to cut.

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-only fetch with no output schema, the definition covers the basic contract and notes the source-code payload. It leaves out the shape and size of the return, the meaning of workspace_id, and any relationship to get_transformation, which is a moderate but not severe gap given the annotations.

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 only 50%: library_id is documented as coming from list_transformation_libraries, but workspace_id has no description anywhere. The tool description contributes nothing about either parameter, so the undocumented half remains unexplained.

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 (transformation library) and adds that source code is included. It is distinguishable from the sibling list_transformation_libraries, though it does not explicitly differentiate itself from get_transformation, which sits adjacent in the tool 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?

The description gives no guidance on when to use this tool versus list_transformation_libraries, get_transformation, or sample_transformations. The only indirect hint is the schema note that library_id comes from list_transformation_libraries, which implies a list-then-get flow but is never stated as usage 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the fact that the response carries processing status and optional table details, which is largely restated in the schema; it says nothing about pagination behavior, ordering, or default time window for the history.

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 repetition. It is efficiently sized, though the space saved could have been used to resolve the sibling overlap.

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?

Annotations cover the safety profile and the schema covers all seven parameters at 86% coverage, so the remaining burden on the description is small. The one real gap is the unresolved ambiguity with get_warehouse_upload_with_tables, which the description never addresses.

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 86%, so parameters (limit, offset, status enum, source_id, destination_id, include_tables) are already well documented structurally. The description adds no meaning beyond the schema — even the 'optional table details' phrase merely echoes include_tables.

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 warehouse upload history") plus the payload contents (processing status, optional table details), which is far more informative than the bare name. However it does not distinguish itself from the sibling get_warehouse_upload_with_tables, even though this tool's include_tables flag appears to overlap that sibling's purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use, when-not-to-use, or alternative guidance. The obvious question an agent would have — should I call this with include_tables=true or call get_warehouse_upload_with_tables? — is left entirely unanswered by the description.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds the useful detail that the payload is table-level processing information, but says nothing about pagination, error behavior when the upload_id is invalid, or whether the upload must belong to the given workspace.

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 filler, so nothing is wasted. It is arguably too terse for a tool with an undocumented parameter, but structurally it is clean.

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, the description is the only place the return shape could be described, and 'detailed table-level processing information' is only a hint. For a two-parameter read tool with full annotations this is adequate but leaves real gaps around the return contents and the workspace_id requirement.

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 only 50%: upload_id is documented as coming from get_warehouse_uploads, but workspace_id has no description anywhere. The description text adds no meaning about either parameter, such as format, sourcing, or the constraint that the upload must belong to that workspace.

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 ('Get') and a specific resource ('table-level processing information for a specific warehouse upload'), which implicitly separates it from the sibling get_warehouse_uploads that lists uploads. It does not explicitly name that sibling as the alternative, 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?

There is no explicit when-to-use or when-not-to-use guidance in the description. The only routing hint comes from the schema's 'ID from get_warehouse_uploads' note, which tells the agent this is a drill-down call but is not part of the description itself.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that — no note on what categories of settings are returned, permission requirements, or whether any fields are sensitive or truncated.

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 front-loaded sentence with no padding, which is structurally fine. But brevity here comes at the cost of substance rather than from efficient wording — nothing was trimmed because nothing was there.

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 annotations covering safety, the main remaining need is what the return payload contains, since there is no output schema. The description never says which settings or detail groups are returned, leaving the agent guessing at the result 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 single required parameter workspace_id has 0% schema description coverage, so the schema gives the agent no meaning at all. The description does not compensate by explaining the ID format or where an agent obtains a valid workspace_id.

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 verb ("Get") and a resource ("workspace details and settings"), which is enough to tell it apart from the audience/source/destination getters in the sibling list. However, "details and settings" largely restates the tool name get_workspace_settings, so the agent learns little about scope or granularity.

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 related tools such as user_details or the various list_* siblings, and no prerequisites are mentioned. 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds value beyond that by disclosing the workflow role and the exact return shape (id, name, tableRef per subject), letting the agent chain straight into create_audience without guessing.

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 sentences, each earning its place: what it lists, when to call it plus the required follow-up action, and what it returns. Front-loaded and free of 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?

With no output schema and a thin parameter schema, the description compensates well by describing return fields and the downstream create_audience handoff. The only residual gap is the undocumented workspace_id parameter, a minor omission for an otherwise simple single-input read tool.

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?

Only one parameter (workspace_id) with 0% schema description coverage, so the description carries the burden but never explains the workspace scoping. The mention of passing an id as `from` clarifies the tool's output consumption rather than its input, so parameter semantics remain adequate but unenriched.

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 ('Lists the candidate subjects an audience can be about') and grounds it with a concrete definition ('root entities of the workspace's data graph') plus examples (Customers, Users, Accounts). This clearly separates it from siblings like list_profiles or get_audience_model_context.

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 positions the tool as 'the first step when authoring or exploring audiences' and tells the agent exactly what to do next: pick the matching subject and pass its id as `from` when creating an audience. It lacks explicit when-not guidance or named alternatives, which keeps it from a 5.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description's help. The description adds only the notion that this returns link-level records while details live elsewhere; it says nothing about pagination, result size, or whether an unfiltered call returns all workspace connections.

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, front-loaded with the purpose and followed by the escalation path to detail tools. Nothing is redundant or padded.

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 three-parameter read-only list tool with no output schema, the description is close to adequate, and the annotations carry the safety semantics. The gaps are the undocumented workspace_id scope and the absence of any statement about what a connection record contains or how results are bounded.

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 a middling 67%: sourceIDs and destinationIDs are documented in the schema, but workspace_id has no description anywhere. The description's phrase "linking sources to destinations" only loosely gestures at the two filter parameters and adds no syntax, combination, or scoping meaning beyond what the schema already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb plus resource ("List connections") and clarifies the domain object as "linking sources to destinations," which is meaningfully more informative than the bare tool name. It does not, however, distinguish this from other list_* siblings (list_sources, list_destinations) beyond the object type.

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 routing hint toward get_source and get_destination for configuration details, which implicitly frames this tool as the lightweight enumeration step. But it never states when to call list_connections versus the sibling lists, or whether filters should be used to narrow results.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that — no mention of event retention, ordering, or what a page of results contains.

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 with no filler, so it is concise. However, the brevity comes at the cost of information, making it under-specified rather than efficiently worded.

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, the description should at least hint at return shape (event fields, ordering, pagination limits). Combined with an undocumented required parameter, the definition leaves an agent without enough to call 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 coverage is only 50%, and the undocumented workspace_id parameter is the required one. The description does not explain what workspace scoping means here or how paging interacts with it, so it fails to compensate for the schema 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 'List events in the data catalog' is essentially a restatement of the tool name list_data_catalog_events. It gives no indication of what kind of events (audit, schema-change, catalog mutation) or their scope, and does not distinguish it from sibling list_data_catalog_properties or audit_logs.

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 audit_logs or list_data_catalog_properties, and no stated prerequisites. The agent must infer the use case purely 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered elsewhere. The description adds nothing beyond that: it does not explain what a "data catalog" scope means here, how pagination behaves, or what the result set 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?

A single short sentence with no wasted words and a clear front-loaded verb. However, brevity here comes at the cost of under-specification rather than efficient communication.

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, the description should convey what is returned (property names, types, pagination metadata) and does not. Combined with the undocumented required workspace_id parameter, an agent cannot confidently predict either the inputs or the results 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 coverage is only 50%: workspace_id is required but has no description anywhere, and the description does not compensate by explaining what a workspace scope implies. Only page carries a schema-level description, so the description contributes no parameter meaning at all.

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 concrete verb and resource ("List event properties in the data catalog"), which separates it reasonably well from siblings like list_data_catalog_events and get_source_event_properties. It stops short of explicitly naming how it relates to those neighbors, so the distinction is inferred 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?

There is no guidance on when to use this tool versus list_data_catalog_events (events) or get_source_event_properties (properties attached to a source). No prerequisites, no scoping conditions, and no exclusions are given; an agent must guess 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the meaningful behavioral fact that the activation_capable filter constrains results to only those destinations the downstream schema/connect tools support, but it says nothing about result volume, pagination, or ordering.

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, both front-loaded with the key noun and no redundancy. The second sentence is dense with routing information but every clause (filter, entry-point role, downstream consumers) 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 read-only list tool with strong annotations, the definition covers purpose, routing, and the key filter semantics. With no output schema, an agent still lacks any sense of what a returned destination record looks like at the top level, whether results are paginated, and why workspace_id is mandatory.

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 67% and activation_capable plus destinationDefinitionName are both well documented inline, including the preserved rudderAccountId context. The description reinforces the activation_capable meaning but adds no syntax, format, or default guidance, and workspace_id remains undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ("List destinations in the workspace") and further scopes the second sentence to activation-capable destinations. It does not explicitly differentiate itself from siblings like get_destination or get_destination_definitions, so an agent must infer the distinction, but the core 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?

It gives explicit when-to-use direction: pass activation_capable=true as the entry point for data-graph audience activation flows, and names the downstream tools (get_audience_destination_schema / connect_audience_destination) that consume the results. It stops short of stating when NOT to use this tool or pointing to get_destination_definitions as the alternative for definition-level lookups, which the schema hints at.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds nothing beyond that — no mention of pagination, result ordering, result size, or whether it returns all projects or a filtered subset, which matters for a listing 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 or redundancy, and the resource is front-loaded after the verb. Its brevity is efficient, though the shortness reflects under-specification rather than disciplined editing.

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 one required, undocumented parameter, no output schema, and no parameter descriptions, the description should carry more weight than it does. Annotations cover safety and idempotency, so the gap is not fatal, but an agent gains little understanding of what a 'profile project' record looks like or how to use the returned 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 0% for the single required parameter workspace_id, so the burden falls on the description. The phrase 'in the workspace' hints that the parameter scopes results to a workspace, but it never states what a workspace_id is, how to obtain it, or whether the list is filtered by it — the schema remains effectively undocumented.

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 verb and resource ('List profile projects'), but 'profile projects' is ambiguous — it is unclear whether these are RudderStack Profiles projects, audience profiles, or profile-related resources. It does not distinguish the tool from siblings like get_profile_details or get_profile_artifacts, which an agent would need to choose between.

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 statement of prerequisites, and no reference to alternatives such as get_profile_details for a single profile. The agent must infer from the name alone whether this is the right entry point.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds only the 'pre-built' scope and does not explain workspace scoping, pagination, return shape, or the effect of include_code; that is adequate for a simple read-only list but thin.

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. Every word contributes to the purpose, and the description is appropriately sized for this low-complexity listing tool.

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?

Although this is a low-complexity read-only list, the description omits important context: required workspace scoping, what a library record contains, and how it differs from sibling list_transformation_libraries. With no output schema and only 50% parameter description coverage, too much is left 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 50%: include_code is documented in the schema, but the required workspace_id is just a string with no description. The description adds no parameter meaning and does not compensate for the missing workspace_id semantics.

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 pre-built RudderStack transformation libraries.' The purpose is clear, though the description does not distinguish this tool from the closely named sibling list_transformation_libraries or from get_transformation_library.

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 list_transformation_libraries, get_transformation_library, or list_transformations. No prerequisites, exclusions, or alternative-selection criteria are given, so usage is only implied by the verb 'List.'

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered by structured data. The description adds genuine value by enumerating the returned payload for both source families (sourceId, name, sourceType, writeKey, enabled status, query/table info), which matters because there is no output schema. It is silent on pagination or result-size limits for a 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?

Two sentences, with the resource and scope front-loaded before usage context and return shape. The second sentence is dense with field enumerations but each item is informative rather than filler; minor trimming of the 'including ... ' clauses would tighten it.

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 nested objects, describing the return collections is necessary and is done for both source families. The main residual gap is the required workspace_id parameter and any pagination behavior, which leaves the definition slightly short of fully self-sufficient.

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 67%: retl_type and sourceDefinitionName are richly documented in the schema itself, so the description's 'filtering options by type and definition' adds nothing beyond that. The required workspace_id has no schema description, and the description does not compensate by explaining workspace scoping or expected format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Retrieve all configured sources') and immediately scopes it to two sub-kinds, event-stream and RETL sources, which distinguishes it from the singular sibling get_source. It does not name any sibling explicitly, so the differentiation is inferable 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 offers usage context ('when you need to see available sources for connecting destinations, analyzing data flow, or managing source configurations'), which is enough to place the tool. However, there is no exclusion guidance telling the agent when to use get_source or get_source_definitions instead, so the when-not half is missing.

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?

Annotations already declare the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the description only needs to add context. It does so by describing what comes back – status, impact, and affected components – which is valuable since no output schema exists. It omits pagination, result-count limits, and how far back "recent" reaches.

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, no filler, with the purpose front-loaded and the return-value detail second. Every clause carries information the agent needs, especially given the absent output schema.

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-only listing tool with one optional param, rich annotations, and no output schema, this covers purpose and expected return content adequately. It falls short of complete only in not clarifying pagination/recency bounds or the distinction from get_statuspage_incident.

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 a single optional parameter whose schema coverage is 100%, so the schema already explains the query filter fully. The description never mentions the query parameter or how filtering interacts with the incident summary, so it adds no meaning beyond the schema – 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 incidents from the RudderStack status page") and scopes it to recent incidents. It implicitly distinguishes itself from the singular sibling get_statuspage_incident, but never names that alternative 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?

Usage is only implied by the phrase "recent incidents" – the agent can infer this is the browse-everything tool versus a single-incident lookup, but there is no explicit when-to-use, when-not-to-use, or named alternative. No prerequisites or caveats 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered externally. The description contributes one behavioral detail — that schemas are optional and add weight to the response — but says nothing about pagination behavior, response shape, or what happens for an invalid plan ID.

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, and the key scope ('tracking plan') plus the notable option ('schema details') both appear immediately. It is efficient, though its brevity borders on under-specification for a tool with two required IDs.

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, closed-world list tool with full safety annotations and no output schema, the definition is workable. It nonetheless omits the relationship to list_tracking_plans as a discovery step and gives no sense of what an 'event' record contains or how pagination terminates, leaving gaps an agent would want filled.

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 75%, just under the high-coverage threshold, and the schema already explains page, includeSchemas (including its response-size warning), and the tracking_plan_id provenance. The phrase 'optional schema details' is the only param-related meaning the description adds, which is marginal beyond includeSchemas' own schema text.

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 ('List events in a tracking plan') and adds the scoping modifier 'with optional schema details'. This clearly distinguishes it from list_tracking_plans (which lists plans, not their events), though it does not explicitly separate it from siblings like get_source_event_schemas or list_data_catalog_events.

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 prerequisites, and no named alternatives. The fact that a tracking_plan_id from list_tracking_plans is required appears only in the schema, not the description, and the description never says when to prefer this tool over the event-schema 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?

The annotations already establish a safe, read-only, idempotent operation, while the description adds limited result context by mentioning governance and validation rules. It does not clarify whether those rules are returned or used as filters, nor disclose pagination, ordering, or other result-scope 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 statement is front-loaded with the operation and resource and contains no filler. However, its compressed wording leaves “with governance and validation rules” ambiguous and omits scope that could have been stated briefly.

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 minimally adequate for a simple one-parameter, read-only listing whose safety behavior is covered by annotations. The lack of an output schema and parameter documentation makes the ambiguous rule content, missing workspace scope, and absent differentiation from related tracking-plan tools meaningful gaps.

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?

With 0% schema description coverage, the description needed to explain the sole workspace_id parameter, but it never mentions workspace scoping or how to obtain the ID. The parameter name is reasonably self-explanatory, but the description itself adds no parameter semantics.

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—listing tracking plans—and adds governance and validation rules as relevant content. It does not distinguish this tool from siblings such as get_source_tracking_plans_and_versions or list_tracking_plan_events.

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 explicit when-to-use guidance, prerequisite, or alternative-tool routing. An agent must infer that this is for general tracking-plan discovery rather than event-, violation-, or source/version-specific queries.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered elsewhere. The description adds only the "custom" qualifier, disclosing nothing about pagination, result size, or what fields each library entry carries.

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, front-loaded with the core action and followed by the natural next step. No filler, though the second sentence is a pointer rather than a description of this tool.

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 list tool with annotations covering safety and no output schema, so expectations are modest. Still, the description never indicates what a listed library looks like (name, id, timestamps), leaving an agent to discover the return shape only after calling.

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 0% for the single workspace_id parameter, so the description must carry that burden. "in workspace" weakly maps to workspace_id but adds no format, required-ness, or scoping semantics beyond the schema's own required list.

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 clear verb+resource ("List custom transformation libraries") and scopes it to "in workspace," which separates it from the broader list_transformations and the sibling list_rudderstack_transformation_libraries implied by "custom." It does not explicitly name that sibling, so it stops 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 second sentence points to get_transformation_library as the follow-up when code is needed, which is useful sequencing guidance. However, it gives no when-not guidance and never contrasts with list_rudderstack_transformation_libraries, so an agent must infer which list tool applies.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful return-content context (metadata and destination connections), but says nothing about result volume, pagination, or ordering — the practical traits an agent still needs.

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, front-loaded sentence with no filler or repetition. It is efficient, though it spends its only clause on payload contents rather than on the routing guidance that would be more valuable.

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, non-destructive read with no output schema, the definition covers purpose and rough return content, and annotations carry safety. Missing are pagination/limit behavior and differentiation from sibling read tools, which keeps it short of full 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 coverage is 0% for the single workspace_id parameter, so the description must carry the meaning. "In the workspace" implies that workspace_id scopes the listing, but it never states format, required-ness, or effect. Marginal compensation for the 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 gives a specific verb and resource ("List all transformations") plus the scope ("in the workspace") and the payload (metadata and destination connections). It does not, however, distinguish itself from siblings such as get_transformation or list_transformation_libraries, 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 when-to-use guidance and no mention of alternatives like get_transformation for a single record or list_transformation_libraries. The listing intent is implied by the verb, but nothing tells the agent when this tool is the right choice over its many 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating. The description adds the sequencing contract with the mutation tools, which is real behavioral context. It does not say what the returned grammar looks like or whether it is workspace-scoped, and with no output schema that remains a small 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?

Two short sentences: the first states the resource, the second the ordering constraint. The mandatory precondition is front-loaded with no wasted wording.

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 low-complexity, read-only, single-parameter tool, and the description covers its purpose and its required call order. Only the workspace_id semantics remain unexplained, which is minor for a tool whose main job is sequencing rather than filtering.

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 workspace_id has 0% schema description coverage and the description says nothing about it. It is not explained whether the grammar is workspace-specific, whether an invalid workspace id fails, or whether the skill is cached per workspace, so the description adds no meaning beyond the parameter name.

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: 'Returns the expression grammar for RudderStack Data Graph audiences.' It also names the sibling tools (create_audience, update_audience) whose expressions that grammar governs, so an agent can tell what this tool produces and where it fits.

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 an explicit mandatory precondition: 'MUST be called before `create_audience` or `update_audience`.' That is a concrete rule for when to use this tool versus calling the audience mutation tools directly, so nothing is left 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new information by disclosing the three return values, which matters because there is no output schema. It does not warn about estimation cost/latency or explain the resume_id continuation behavior, which are the remaining 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?

Two dense sentences with no filler, and the hard prerequisite is front-loaded ahead of the purpose and lifecycle context. Every clause carries actionable content.

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 read-only preview tool with no output schema, the definition covers the prerequisite skill, the intended lifecycle position, and the returned metrics. It stops short of describing the continuation flow implied by resume_id or failure/validation behavior, which would matter for a tool whose whole job is validating expressions.

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 75%, so most parameters are already documented in the schema, including the 'where' omission behavior and the resume_id instruction. The description adds only indirect meaning, tying 'where' to the create/edit cycle; it does not explain 'from', 'workspace_id', or when a resume_id round-trip occurs. 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 and resource ('Estimates an audience's size') and then enumerates the three outputs it produces: matching row count, subject universe count, and percentage. This separates it cleanly from siblings like create_audience and update_audience, which consume rather than evaluate an expression.

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 a hard prerequisite ('MUST call `load_audience_skill` before using this tool') and a precise placement in the workflow ('during the create/edit cycle ... before calling `create_audience` / `update_audience`'). The schema further clarifies the 'where'-omitted case, so an agent knows both when to call it and when it is not yet safe to call it.

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?

Annotations already declare this as a read-only, idempotent, closed-world operation, so the safety profile is covered. The description adds only that the templates are pre-built for common use cases; it says nothing about what the returned list contains, whether it is filtered by workspace, or how it differs from the other library tools.

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 short sentence with no filler. It is efficient but perhaps too terse given the tight sibling set and required parameter.

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?

There is no output schema, and the description does not explain what the returned templates include. Combined with 0% schema coverage on the required workspace_id and no sibling differentiation, this leaves an agent without enough information to invoke 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?

The schema has zero description coverage and one required parameter, workspace_id, which the description does not mention at all. An agent gets no explanation of what workspace scoping means here or whether the templates returned depend on that workspace.

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: browsing pre-built transformation templates. However, it does not distinguish this tool from sibling tools such as get_transformation_library, list_transformation_libraries, and list_rudderstack_transformation_libraries, which all appear to return transformation templates in some form.

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 guidance about when to use this tool instead of the several related library and listing tools. An agent cannot tell from the description whether this is the canonical starting point for templates or a subset of them.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only that results come from semantic (not keyword) search, and says nothing about ranking, result caps, or return shape. That is modest added value beyond the structured fields.

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 front-loaded sentence with no filler, and the key differentiator (semantic search) is stated immediately. It is arguably too terse rather than padded, so it is not penalized for verbosity.

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 essential facts are present, but the description never indicates what a result contains (doc snippets, URLs, scores) or how the semantic search behaves on no-match queries. A short note on return content and on ask_docs would 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 coverage is 50%: num_results is documented in the schema with a default and max, but query has no description. The description adds nothing about query phrasing or the effect of num_results. Baseline 3 applies since the schema carries most of the load for a two-parameter tool.

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 (Search) and resource (RudderStack documentation) and adds the mechanism (semantic search), which distinguishes it from a generic lookup. However, it does not differentiate itself from the sibling ask_docs, which plausibly covers the same documentation corpus from a question-answering angle.

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 versus ask_docs, or when semantic search beats a direct docs lookup. The agent must infer the choice from tool names alone, and no exclusions or prerequisites are given.

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?

Annotations declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, but the description says only 'test ... against sample events', which reads as harmless. It never explains that the transformation code actually executes, what side effects could occur, or why the operation is flagged destructive — so it adds little beyond the annotation flags and arguably softens them.

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 repetition. It is efficient, though the terseness leaves no room for structure such as a usage note or return-value hint.

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?

There is no output schema, so the description should explain what a test returns (pass/fail per event, transformed payload, errors) — it does not. Combined with an unexplained destructiveHint and an undocumented workspace_id, an agent cannot predict the outcome or risks of 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?

Schema coverage is 67%: 'input' has a detailed JSON example and 'transformation_id' points to list_transformations, while 'workspace_id' is undocumented. The description adds no parameter meaning at all, so the schema does the heavy lifting; baseline 3 is appropriate for this coverage level.

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 ('Test') and resource ('an existing saved transformation') plus the input kind ('sample events'). The word 'existing' implicitly contrasts with the sibling transformation_test_new, so an agent can pick between the two, though the sibling is never named 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?

Usage is only implied: 'existing saved transformation' suggests using this for transformations already created, and transformation_test_new for unsaved ones. There is no explicit when-to-use/when-not statement, no prerequisite (e.g., transformation must already exist in the workspace), and no mention of alternatives.

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?

Annotations declare destructiveHint=true, idempotentHint=false and openWorldHint=true, which is surprising for something framed as a 'test'. The description does nothing to explain what is destructive, whether the code is sandboxed, whether test runs touch production pipelines, or how errors surface. Since annotations already flag risk, the description should have clarified the side-effect model but instead only restates the name.

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, the core action front-loaded and the pointer to sample_transformations second. 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?

With four parameters, no output schema, and a destructive annotation, an agent needs to know what a test run returns (transformed events, errors, logs) and what persists after the call. The description covers neither, so it is adequate but leaves meaningful gaps for a tool flagged as destructive.

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 75% and the schema already documents code format, the input JSON example, and the language enum. The description only alludes to 'sample events' (mapping loosely to input) and adds no syntax or constraint detail for workspace_id, which has no schema description at all. 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?

The description gives a specific verb and resource: testing transformation code against sample events. That distinguishes it in spirit from transformation_test_existing and from get_transformation, though it never explicitly says 'use this for unsaved/new code, not deployed transformations', leaving the distinction to the tool 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?

It offers one useful routing hint – pull starter templates from sample_transformations – which tells the agent how to bootstrap the code parameter. However, it never states when to prefer transformation_test_existing, nor whether a transformation must already exist in the workspace, so usage 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral context with "Omitted fields are preserved," clarifying that this is a partial/patch update rather than a full replace. It leaves the destructive replace semantics of `where` and `tags` to the schema rather than reinforcing them here.

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, zero filler, with the core action first and the blocking prerequisite immediately after. Every clause conveys information an agent needs before invoking the tool.

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 six-parameter mutation with a nested `where` object and no output schema, the description covers the essentials: the action, the mandatory skill prerequisite, and patch semantics. The gap is the absence of any return/confirmation behavior and no reinforcement of the destructive replacement of `where`/`tags`.

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 83%, so the schema already carries most parameter meaning, including that `tags` and `where` fully replace existing values. The description's "Omitted fields are preserved" adds useful optional-parameter semantics but does not address the two required IDs or the shape of `where` beyond pointing at the skill. Baseline 3 is appropriate given the strong 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 and resource ("Updates a RudderStack Data Graph audience"), which cleanly separates it from create_audience, get_audience, and preview_audience in the sibling list. It stops short of naming those siblings explicitly, so the differentiation comes from the verb rather than from a direct contrast.

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?

"MUST call `load_audience_skill` first" is a hard, explicit prerequisite that an agent could otherwise miss, since the `where` schema is an empty object shaped by that skill. It does not, however, state when to choose update_audience over create_audience or preview_audience, so the when-not guidance is absent.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=false and idempotentHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond that: it doesn't say that supplying an id overwrites existing code, that language is immutable on update, or that a release tag/version is created on insert — all points an agent needs and none of which are stated here.

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?