OutSend

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, covering the safety profile. The description adds that the operation is async and returns the new job id, which is useful but not extensive.

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 efficient sentences with the core action front-loaded, a helpful parenthetical list of enrichment types, and a clear note on the return value. No wasted words.

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

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

Given no output schema and annotations covering safety, the description adequately covers the async nature, return value, and enrichment scope. Minor gaps remain around non-idempotency and how to track the new job (though get_job is a sibling).

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 the schema does most of the work. The description adds value by listing concrete enrichment examples (emails, reviews, socials, verify_emails, techstack) that map to enum values, clarifying the 'enrichment' parameter beyond the bare enum.

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 'Enrich' and resource 'results of a finished job', and notes it is async. It does not explicitly differentiate from siblings like create_scrap_job or create_pipeline, but the action is distinct.

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

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

The phrase 'results of a finished job' implies the tool should be used after a job completes, but there is no explicit when-to-use, when-not-to-use, or alternative tool 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, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so safety framing is covered. The description adds genuine runtime context beyond that: the monitor re-runs periodically and produces a new/removed/modified diff. It does not disclose what is returned at creation or any permissions required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that states the action and the resulting behavior with no filler. Every clause (recurring, every N days, diff of new/removed/modified) carries 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 4-parameter creation tool with no output schema and 0% schema description coverage, the description leaves gaps: the meaning of 'name', the job-vs-pipeline exclusivity, and what the call returns are all unaddressed. It is adequate on behavior but thin on invocation detail.

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% across 4 parameters, so the description carries the full burden. It accounts for 'job or pipeline' (source_job_id / source_pipeline_id) and 'every N days' (frequency_days), but says nothing about the required 'name', the 1-90 day bound, or whether the two source parameters are mutually exclusive.

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 action (create a recurring monitor) and resource, and explains the resulting behavior: re-running a job/pipeline every N days and diffing results. It implicitly separates itself from one-shot siblings like create_scrap_job or create_enrichment_job, though it never names an alternative.

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: 'turn a finished job or pipeline into recurring monitoring' suggests the precondition that a job/pipeline already exists and has run. There is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as list_monitors or create_pipeline.

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=false, idempotent=false, openWorld=true), so the bar is lower, and the description still adds real behavior: the pipeline is started on creation, chains are strictly linear, and the call returns pipeline id plus initial job ids. The 'from'/'to' key gotcha is a useful implementation detail. It does not cover rate limits, auth, or failure behavior, keeping it short of a 5.

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 the action, then constraints, then the schema pointer, then a single example. Dense but every element earns its place; the example is the right length for a nested-object payload.

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, so stating the return value (pipeline id + initial job ids) is necessary and present. For a nested-object mutation with a sibling schema-lookup tool, the description supplies enough to construct a call, though a note on whether jobs are charged or how to track them would complete the picture.

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 67% schema coverage the schema documents the definition shape and low_priority, but the description compensates for the weaker spots by showing a full worked example and explicitly warning that edge keys are 'from'/'to' not source/target. Only the 'name' parameter is unaddressed anywhere.

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?

Starts with a specific verb+resource ('Create AND start a multi-step pipeline') and immediately distinguishes itself from the sibling job-creators by naming it a pipeline of chained blocks. The example definition makes the resource concrete.

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 routes the agent to get_pipeline_schema for valid block types and config fields, which is a genuine alternative/dependency pointer. It does not, however, say when to choose a pipeline over sibling tools like create_scrap_job or create_enrichment_job, so the exclusion set is left implicit.

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

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

Adds real context beyond the annotations: async execution, immediate job-id return, background run until status=done, stop_at capping unique places, and the foreign-phone drop default. Annotations already cover readOnly/openWorld/idempotent, so this is a solid addition on top of 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?

Three dense sentences, front-loaded with the launch/async fact, then return value, then the two behavioral knobs. No filler, though the parenthetical '(async)' and the restated exclude_foreign_phones default add minor redundancy.

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

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

Acknowledges the async model and status=done but never names get_job or get_job_results for retrieving output, which matters since there is no output schema. With 8 parameters at 25% coverage, several inputs remain unexplained for a job-creation 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 25% of 8 params are schema-documented, and the description explains just two: stop_at (caps unique places, beyond the bare schema) and exclude_foreign_phones (largely restating the schema text). country, scrap_mode, max_per_phone, extra_columns, queries, and zones get no clarification.

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 ('Launch a Google Maps extraction'), which distinguishes it from the enrichment, monitor, and pipeline job siblings. It does not explicitly name those siblings, but the 'Google Maps extraction' scope makes the domain clear.

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

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

No when-to-use guidance and no mention of estimate_scrap, the obvious companion tool for sizing a job before launching it. The async/job-id mechanics are stated, but that is behavior, not selection 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 cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), and the description adds genuine context beyond them: nothing is launched and therefore no EF is consumed, plus the EF unit of measure. It does not disclose auth requirements or whether the estimate is binding.

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 action and scope, followed by the one piece of unit information needed to interpret the result. 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?

Although there is no output schema, the description names what the call returns (cost in EF and volume), which is the key unknown for a 5-parameter estimation tool. The only real gap is the unexplained scrap_mode enum, which affects the accuracy of the estimate.

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 explains queries, zones, country and stop_at; baseline is 3. The description adds no parameter-level guidance, and the one enum (scrap_mode: fast/normal/ultra) has neither a schema description nor any explanation in the description.

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 ('Estimate the cost (EF) and volume of a Google Maps extraction') and explicitly carves out the scope with 'WITHOUT launching it', which separates it from create_scrap_job. The EF unit definition further pins down what 'cost' means in this domain.

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

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

The phrase 'WITHOUT launching it' makes the pre-flight use case clear: call this before spending quota on a real extraction. It does not name create_scrap_job as the alternative or state explicit exclusions, so it falls short of a full when/when-not rule.

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 read-only and non-destructive behavior, so the safety profile is covered. The description adds the cursor-based pagination mechanism, which is useful, but doesn't mention rate limits, ordering, or retention. Adequate with annotations but not rich.

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 and followed by pagination detail. No wasted words; efficient but could include more parameter context without bloat.

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

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

The tool has 3 parameters with no schema descriptions and no output schema. The description explains one parameter and the event concept, but leaves limit and types undocumented and doesn't explain return shape or pagination termination. Gaps remain for correct invocation.

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%, so the description should explain all parameters. It only clarifies since_id semantics (takes last_id) but doesn't describe limit or types. Partial compensation yields a baseline 3.

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

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

The description states it is an 'Account event feed' and gives concrete examples of event types, distinguishing it from sibling CRUD tools. It doesn't explicitly contrast with list_jobs, but the resource (events) is clear.

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

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

Usage is implied by the cursor-based explanation and event examples, but there's no explicit when/when-not guidance or reference to alternatives. An agent can infer this is for polling events, but no prerequisites 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 establish this as a safe, non-destructive, non-open-world read, so the safety profile needs no restating. The description does add value by enumerating what the response contains (status, counters, download URL), which matters since there is no output schema. It still omits behavioral traits such as behavior for unknown/finished jobs or polling expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with the key content front-loaded and zero filler. It is appropriately sized, though as a fragment it carries no structural signposting for an agent that needs more than the return contents.

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

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

For a one-parameter read tool with annotations covering safety, the description does cover the return contents, which is helpful given no output schema. It remains incomplete on the two things an agent most needs: how this differs from get_job_results and whether/how to poll for an in-progress job.

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% and the single parameter job_id is documented nowhere. The description never mentions the parameter, where to obtain it, or any format expectation, so it fails to compensate for the coverage gap. Only the obviousness of the name keeps this above 1.

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 the resource content it returns (status, counters, download URL of a job), which is more specific than a bare verb. However, it is a noun phrase with no verb and does not distinguish itself from the sibling get_job_results, which an agent could easily confuse it with. Purpose is understandable but sibling differentiation is absent.

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 poll this tool, when to prefer get_job_results instead, or any prerequisite (e.g. needing a job_id from a create_* tool). The description only states what comes back, leaving selection entirely to inference.

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

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

Annotations already establish the safe read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description only needs to add operational context — and it does: the 50-row per-call cap, offset-based pagination, and the escape hatch of a full-export download URL. It omits error behavior for unfinished or expired jobs, which keeps it out of the top band.

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 sentence that front-loads the primary output (row preview) and then adds the secondary outputs (count, CSV URL) and pagination mechanics. Every clause earns its place and nothing is repeated from structured fields.

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 must describe return values, and it covers all three (rows, total count, CSV URL) plus the pagination contract. The remaining gap is failure/edge behavior — unfinished jobs, expired results, or what the CSV URL's lifetime is.

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%, so the description must carry parameter meaning, and it does for two of three params: "max 50 per call" explains limit's practical cap and "paginate with offset" explains how offset is used. job_id is left undefined, though it is self-evident from context.

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 precisely what is returned — a row preview (capped at 50, offset-paginated), a total count, and a CSV download URL for the full export — which makes it clearly distinct in substance from sibling get_job (job status) and list_jobs. It never names those siblings, so the differentiation is implied rather than explicit.

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?

"a finished job's rows" conveys the precondition that the job must be complete, and the CSV download URL functions as the routing signal for agents that want the full dataset rather than a paginated preview. There is no explicit when-not guidance, e.g. what to do while a job is still running.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the payload is a static contract rather than live data, but says nothing about format (JSON Schema?), size, versioning, or caching 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 that defines the artifact and its three components with no filler. Every clause 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?

With no parameters and no output schema, the description must carry the return-value burden, and it does so by naming the three sections of the contract. It is slightly thin on payload format and on how an agent should use the chaining rules, but it is adequate for a zero-arg schema fetch.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly indicates the tool is a no-argument reference lookup, leaving no parameter semantics to explain.

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 resource and enumerates exactly what the returned contract contains (valid block types, per-block config schema, chaining rules). Naming create_pipeline as the consumer cleanly separates this reference tool from its write-side 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?

'accepted by create_pipeline' implies this is the lookup to perform before building a pipeline, which is useful routing context. However, it never states explicitly when to call it, that it takes no arguments, or that it should be consulted before create_pipeline rather than after a validation failure.

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, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds one genuine behavioral fact beyond them: results are ordered newest first and limited to 'recent' jobs. It does not disclose the default limit, whether 'recent' is a fixed window, or any pagination behavior, so it remains 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 short sentence with the scoping and ordering information front-loaded and no filler. It is efficiently sized, though as a noun fragment it is arguably under-specified rather than concise.

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

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

With no output schema, an undocumented parameter, and twelve sibling tools, the description should carry more weight than one clause. It omits result count defaults, recency window, and any routing to get_job or the other list_* tools.

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

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

Schema description coverage is 0% and the single 'limit' parameter (1-50) is never mentioned in the description, so the agent gets no explanation of what the limit controls or what the default is. The description does not 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 fragment 'The account's recent jobs, newest first' identifies the resource and its scope/ordering, but never states a verb or that this is a listing operation with a bounded result set. Against siblings like get_job, list_monitors and list_pipelines it hints at a collection read but does not clearly differentiate itself beyond the tool name.

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 the sibling get_job for a single job, and no statement of when listing is preferable to get_job_results or get_events. The agent must infer all routing from the tool 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, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds genuinely new context: it discloses the returned content (each module's inputs and outputs) and a status constraint that coming_soon modules cannot be launched, which is behavioral information the annotations do not carry.

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 purpose and followed by the one caveat that matters. Every clause earns its place with no restatement 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?

For a zero-parameter, read-only listing tool with full annotation coverage and no output schema, the description supplies enough to call it correctly and interpret the result. It does not describe the shape of a module entry or any pagination, but that gap is minor at this complexity.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly avoids inventing filter or pagination parameters that do not exist.

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 the specific resource ('outsend data modules') and states what the listing contains ('what each one needs and produces'), which distinguishes it from sibling listers like list_jobs, list_monitors, and list_pipelines. It is a noun phrase rather than an explicit verb+resource, but the cataloging intent is unmistakable.

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 discovery step before launching a module or creating an enrichment/scrap job. No alternative tool is named and no explicit when-to-use or when-not-to-use condition is 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 already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that: no note on scope (all monitors vs. owned), pagination, ordering, or result shape, leaving the behavioral picture entirely to the 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?

Extremely short with no filler, which is good, but the single fragment is under-specified rather than concise — it omits the action verb and any useful detail, so its brevity comes at the cost of informativeness.

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

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

With no output schema and no annotations covering content, the description is the only source of information, and it supplies almost none — not even that the tool returns a list of monitors. For a zero-param listing tool the bar is low, but this still falls short.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is no parameter semantics to explain and the schema is trivially complete. Nothing in the description misrepresents the (empty) input.

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 phrase 'The account's recurring monitors' names the resource and hints at scope ('account's', 'recurring'), but it is a noun fragment with no verb, so it never states that the tool retrieves/lists anything. An agent must infer the action from the tool name alone, and nothing distinguishes it from siblings like list_pipelines or list_jobs.

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

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

There is no guidance on when to use this tool versus alternatives such as list_jobs, list_pipelines, or the get_* family. No prerequisites, no context, no 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only added value is the note that results include pipeline status; it says nothing about pagination or result size, which is what an agent would still want.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no filler, and the key content (pipelines + status) is front-loaded. It is efficient, though arguably under-specified rather than optimally concise.

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

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

For a simple, parameterless read tool with annotations covering safety, the definition is close to adequate. However, with no output schema and no description of the returned record shape beyond the word 'status', an agent still lacks detail on what a pipeline entry contains or whether results are paged.

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 input schema has zero parameters, so there is nothing to document and no schema-coverage gap to compensate for. Baseline 4 applies for a parameterless 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?

The phrase 'The account's pipelines with status' identifies the resource and hints at the returned field ('status'), but is a noun phrase with no explicit verb and does not differentiate it from siblings like list_jobs, list_monitors, or get_pipeline_schema. An agent can infer 'list pipelines' from the name/title, but the description itself adds little differentiation.

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

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

There is no statement of when to use this tool versus alternatives such as get_pipeline_schema (for schema details) or create_pipeline. It does not mention prerequisites, account scoping, or the relationship to other list_* tools in the sibling set.

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