OutSend

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

With no annotations, the description carries the full burden. It discloses that the operation is async and returns a new job id, which is useful. But it omits permissions, side effects on the source job, error behavior, and rate limits, leaving significant 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 sentences, front-loaded with the core action and scope, ending with the return value. No superfluous words; every part contributes.

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

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

For a mutation tool with no annotations and no output schema, the description covers purpose, async nature, and return value. However, it lacks usage guidelines, parameter details, and behavioral specifics that an agent might need to invoke 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 67% (email_mode and source_job_id documented, enrichment not). The description lists enrichment examples but does not explain parameter semantics beyond what the schema already provides, so it adds little value.

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: 'Enrich the results of a finished job (async)' and lists enrichment types. Clearly distinguishes from siblings like create_scrap_job by requiring a finished source job, though it does not explicitly name alternatives.

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?

Mentions the precondition of a finished job and the async nature, giving clear context for when to use. However, it does not provide explicit exclusions or name alternative tools for different scenarios.

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

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

With no annotations, the description carries full burden and does disclose key traits: it both creates and immediately starts the pipeline (a state-changing side effect), and it returns pipeline id plus initial job ids. It omits permissions, error/rollback behavior, and rate limits, so not fully complete.

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-loads the core action, then the constraints, then a useful example — no filler. The example consumes space but earns it by disambiguating the nested 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?

For a mutation tool with no annotations and no output schema, the description covers the essentials: side effect, return values (id + job ids), structural constraint, and payload format. It stops short of edge-case/error and permission details.

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 nested 'definition' object is loosely typed (items: object), so the description must compensate. It does: it specifies the node {id, type, config} shape, the edge {id, from, to} shape, warns that keys are from/to not source/target, and supplies a full worked example.

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

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

States a specific verb and resource ('Create AND start a multi-step pipeline') and scopes it as multi-step, distinguishing it from single-job siblings like create_scrap_job and create_enrichment_job. The inline example makes the intended output 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?

Gives a clear prerequisite ('Call get_pipeline_schema first for the valid block types') and a structural rule ('Keep chains LINEAR'), which tells the agent how to use it. It does not explicitly say when to prefer this over create_scrap_job/create_enrichment_job, leaving that 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?

With no annotations, the description carries the full burden and does disclose the key behavioral trait: the job is asynchronous, returns a job id immediately, and must be polled before results are fetched. It omits other operationally relevant facts such as cost/credits, rate limits, or whether a launched job can be cancelled.

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 compact sentences with zero filler; the purpose and the async contract are front-loaded before the stop_at tip. Every sentence adds actionable 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?

It covers the async lifecycle and the single non-obvious parameter well enough for an agent to launch and follow up, and it compensates for the missing output schema by describing the immediate return value. However, with seven parameters, no annotations, and very thin schema descriptions, the input contract remains substantially under-explained.

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 14%, so the description must compensate, but it explains only one of seven parameters (stop_at). The meanings of scrap_mode values (fast/normal/ultra), max_per_phone, extra_columns, and the intended content/format of queries and zones are left entirely to the bare 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 opens with a specific verb and resource ('Launch a Google Maps extraction') and immediately qualifies it as async, which clearly separates it from enrichment/veille/pipeline siblings by resource type. It stops short of naming which sibling create_* to use instead in a given situation, so it is clear but not explicitly differentiating.

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 concrete downstream routing — poll get_job until status=done, then call get_job_results — and states the condition for setting stop_at ('when the user wants ~N results'). It does not say when to prefer this over create_enrichment_job or estimate_scrap, so no true alternative/exclusion guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the recurring re-run every N days and that a diff of new/removed/modified places is computed, which is real added value, but it omits whether creation is immediate, what side effects occur, permission requirements, or what the call returns.

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 core action front-loaded and zero filler. It conveys the trigger, the recurrence interval, and the output semantics without 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?

With no annotations and no output schema, the description does the main explanatory work about recurring behavior, but it leaves gaps for a creation tool: what entity is produced, how to reference it later, and how the two source parameters interact. Adequate but not complete.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate. It maps loosely to the schema: 'every N days' covers frequency_days and 'a finished job or pipeline' covers the two source id parameters, but 'name' is unaddressed and no format, precedence, or mutual-exclusion rules for the two sources are given.

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 transformation: turning a finished job or pipeline into recurring monitoring, and explains the resource it produces (a veille that re-runs and diffs results). This distinguishes it from siblings like create_pipeline or create_scrap_job, though it never names an 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?

The phrase 'turn a finished job or pipeline into' implies the prerequisite (a source job/pipeline that already ran) and the intent (recurring monitoring), but there is no explicit when-to-use vs when-not, and no guidance on choosing between source_job_id and source_pipeline_id.

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

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

No annotations are provided, so the description must carry behavioral weight. It clarifies this is a non-executing estimation tool, which is crucial for safety, but doesn't mention rate limits, auth requirements, or whether estimates are cached. Adds key context (no launch) but leaves other operational details unstated.

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

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

Two sentences, front-loaded with the action and result, then the critical caveat (WITHOUT launching) and a usage rule. No wasted words.

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

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

For a 5-parameter estimation tool with no output schema, the description covers the essential: what it does, when to use it, and the unit of cost. It could have explained how query×zone combinations scale cost, but the core is complete enough for an agent to invoke correctly.

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

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

Schema coverage is 80%, so most parameters are well-described. The description adds the unit definition ('1 EF = full-France scrape for one query type'), which is valuable conceptual context not in the schema, but doesn't clarify how zones/queries interact with cost scaling. Baseline 3 is appropriate given high schema 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 precise verb+resource: 'Estimate the cost (EF) and volume of a Google Maps extraction'. It also clarifies it does not launch the job, instantly distinguishing it from create_scrap_job. No ambiguity about what the tool returns (cost and volume).

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 says 'Always estimate before creating a large job', giving clear when-to-use guidance and implicitly routing to create_scrap_job as the alternative. This is actionable and unambiguous.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully reveals the cursor/pagination model and that results are an append-only event stream, but says nothing about retention window, event ordering, limits on the feed, or permissions. Partial behavioral context for a read 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?

Two compact sentences, no filler. The resource identity is front-loaded and the cursor mechanic follows immediately. 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 annotations, no output schema, and 0% parameter coverage, the definition leaves notable gaps: what an event object contains, how limit and types behave, and any retention or ordering guarantees. The core purpose and pagination are covered, which is the minimum viable level.

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 three parameters, so the description must compensate. It explains since_id's real semantics (resume cursor sourced from a prior last_id), which is genuine value beyond the bare integer schema, but limit and types are left completely 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+resource (event feed) and grounds it with concrete example event types (job.completed, pipeline.completed, veille.run_completed), which makes the resource scope unambiguous. It does not explicitly contrast itself with siblings like get_job or list_jobs, but the 'feed' framing is distinct enough that an agent can separate it.

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

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

The cursor instruction ('pass back last_id as since_id') gives clear operational guidance for continuing a feed, but there is no statement of when to use this tool rather than list_jobs or get_job, nor any exclusions. Usage is implied by polling semantics rather than stated.

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

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

With no annotations, the description carries the full behavioral burden. It implies a read-only lookup but says nothing about error behavior for an unknown/expired job_id, whether the call blocks, whether results are eventually consistent, or any auth requirements.

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 most useful information (the returned fields) front-loaded and no filler. It is efficient, though the terseness borders on under-specification rather than optimal 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 the description does partially compensate by listing the returned payload (status, counters, download URL). However, for a job-status tool it omits polling/terminal-state behavior and job_id semantics, leaving 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?

Schema description coverage is 0% and the single parameter job_id is undocumented in the schema. The description adds no meaning about the parameter (format, source, where to obtain it), 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?

The description names a specific resource (a job) and enumerates what it returns: status, counters and download URL. That is clearer than a bare restatement of the name and lets an agent infer it is distinct from get_job_results, but it never explicitly names or 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?

There is no guidance on when to call this versus list_jobs or get_job_results, nor any stated precondition (e.g. job must exist, poll until complete). The agent must infer usage entirely from the tool name.

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

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

With no annotations the description carries the full burden, and it delivers real behavioral facts: a hard 50-row cap per call, offset-based pagination, an accompanying total count, a CSV download URL, and the precondition that the job must be finished. It does not cover auth requirements or behavior/errors for unfinished jobs, keeping it below 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?

Two tight sentences, front-loaded with the scope and payload, followed by a directive on how to present results. Every clause earns its place and nothing is 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?

There is no output schema, and the description compensates by naming the return contents (sample rows, total count, CSV URL) and the pagination contract. Combined with the partial parameter coverage, an agent has enough to call it correctly, though the unfinished-job case is 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 0%, so the description must compensate. It clarifies limit (max 50 per call) and offset (pagination), which are the non-obvious two of three parameters; job_id is only implicitly explained via "a finished job's rows." Adequate but not complete given the zero coverage baseline.

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

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

The description gives a specific verb and resource ("Preview of a finished job's rows") and enumerates the payload (rows + total count + CSV URL), so an agent can tell it apart from metadata-oriented siblings like get_job and list_jobs. It falls short of a 5 only because it never explicitly names those siblings or the distinction.

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

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

It states the operating condition (finished jobs), the pagination mechanism, and prescriptive usage — "show a sample, give the link" rather than dumping rows. What's missing is an explicit contrast with sibling tools or a statement of when this preview is the wrong choice.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return content (block types, config schema, chaining rules) and its role as a static contract, but does not state that it is a safe read-only lookup, nor any auth requirements 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?

Two short sentences: the first names what the tool returns, the second gives the imperative ordering. No filler, front-loaded with the contract's purpose.

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

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

With no output schema, the description must convey return content, and it does by naming the three sections of the contract. It omits the response format (e.g. structured JSON schema vs. prose), a minor gap for a zero-argument 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?

The tool takes zero parameters, so the baseline is 4 — no parameter meaning can be lost and the description does not need to compensate for schema gaps. Schema coverage is reported at 100% for an empty object.

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 (pipeline schema) and enumerates its contents: valid block types, per-block config schema, and chaining rules. This clearly distinguishes it from the sibling create_pipeline, which consumes rather than exposes this contract.

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 says 'Use before create_pipeline,' which establishes the correct ordering relative to a named sibling. It stops short of stating when-not to use it or naming other alternatives (e.g. list_modules), so it falls short of a full 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?

No annotations are provided, so the description carries the full burden. It discloses ordering (newest first) and scope ('recent'), which is useful, but says nothing about how 'recent' is bounded, pagination, whether results are stateless, or auth requirements — significant gaps for a list tool with no annotation coverage.

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

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

A single short sentence with the ordering constraint front-loaded and no filler. It earns its place, though the sparseness 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 no annotations, no output schema, and an undocumented parameter, the description is too thin to be complete. It should clarify what 'recent' means, the default and max result count, and how this differs from get_job and get_job_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?

There is one parameter (limit) with 0% schema description coverage and only numeric min/max bounds. The description never mentions the limit parameter, its default value, or its interaction with the 'recent' window, 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 names the resource (jobs), scopes it to the account, and states an ordering (newest first), so an agent knows it is a list operation. However, it does not distinguish this from siblings like get_job, get_job_results, or list_pipelines, which is the sharper part of this dimension.

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 alternative get_job/get_job_results for single-job inspection, and no conditions for choosing this tool over its siblings. Usage must be inferred entirely from the name.

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

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

With no annotations, the description carries the full disclosure burden. It usefully reveals a behavioral trait beyond the name: modules flagged coming_soon cannot be launched, which affects downstream tool selection. However, it says nothing about the read-only nature, response shape, or whether results are cached/static, so the coverage is partial.

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, each doing distinct work: what it returns, when to call it, and a constraint on the returned data. No filler and the most actionable content ("call this first") is near the front.

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 must convey the return value, and "what each one needs and produces" plus the coming_soon status gives an agent a usable mental model of the catalog. It stops short of describing the exact fields per module, but it is sufficient for a zero-parameter discovery 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?

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline is 4. The description correctly does not invent or reference any arguments.

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 resource (outsend data modules) and what the listing contains (what each module needs and produces), which cleanly separates it from the job/pipeline/veille listing siblings. The verb is implicit ("Catalog of...") rather than an explicit action, but an agent can still identify the operation unambiguously.

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 this first to know what is possible" gives explicit ordering guidance for the workflow, which is exactly the kind of when-to-use direction that helps an agent sequence calls. It does not name alternative tools or a when-not condition, but for a discovery/catalog tool no meaningful alternative exists.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: no indication that this is a read-only listing, no mention of pagination, result volume, or ordering. The only behavioral hint is 'with status', which is too vague to act on.

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 wasted words, but it errs toward under-specification rather than conciseness. Nothing is front-loaded because there is essentially only one fragment of 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 listing tool with no annotations and no output schema, the description should at minimum say what a pipeline record contains or how results are shaped. Combined with a crowded sibling set of list_* tools, the definition leaves an agent without enough to decide or interpret 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool applies. No parameter-related gaps 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 phrase 'The account's pipelines with status' names the resource (pipelines) and the scope (the account), but it is a noun phrase with no verb, and 'with status' is ambiguous — it is unclear whether statuses are returned, filtered, or required. It does not distinguish this tool from siblings like list_veilles or list_modules beyond the noun.

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 at all on when to call this instead of list_veilles, list_modules, or get_pipeline_schema. The description gives no prerequisites, no filtering conditions, and 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?

With no annotations, the description carries the full behavioral burden, yet it discloses almost nothing: no statement that the call is a safe read, no indication of whether results are paginated, sorted, or truncated, and no return-shape hint. Only the 'account's' possessive implies scoping.

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 fragment with zero padding; nothing is wasted. It is arguably too terse rather than too long, but conciseness and structure are not the failure point here.

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

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

For a zero-parameter list tool with no annotations and no output schema, the definition is minimally viable: an agent can identify the resource and call it with no arguments. However, it omits anything about the returned collection, ordering, or size, which is the only substantive gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies: the empty schema is self-explanatory.

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 identifies the resource domain (recurring monitors belonging to the account) and usefully disambiguates the French term 'veille' from siblings like create_veille, but it never states the action. An agent must infer 'list' from the tool name alone, and scope (all monitors? filtered?) is unstated.

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

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

There is no when-to-use guidance and no mention of alternatives such as list_jobs, list_pipelines or list_modules, despite a crowded sibling set of read/list tools. The agent is left to guess which listing endpoint is appropriate.

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