Loutre

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

No annotations exist, so the description carries the full burden. It usefully discloses the evaluation model (ordered, first-match-wins, x-loutre-* header priority) — real behavioral value — but says nothing about authorization (ownerToken vs API token), whether adding a duplicate/conflicting rule errors, or how existing rules are affected.

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 the core action front-loaded and no filler. The second sentence earnestly adds evaluation semantics rather than padding, though it could be split for scanability.

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, nested, no-annotation, no-output-schema mutation tool, the description covers matching semantics well but leaves auth requirements and failure/conflict behavior unstated — material gaps given nothing else documents them.

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 documents slug, route, when-subfields, ownerToken and the dotted-path body syntax. The description adds the useful framing that conditions span query/header/path param/body field, but contributes no new detail on status, latencyMs, name, or auth parameters.

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?

Opens with a specific verb+resource: 'Add a conditional response to a route', and immediately clarifies the mechanism (conditions match → mock answers with status, body, latency). This distinguishes it from unconditional siblings like set_response, though it never names any 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?

The description implies the use case (conditional/route-specific mocking) and gives evaluation context ('rules are evaluated in order, first match wins'), but it never states when to prefer this over set_response or set_behavior, nor any prerequisites or exclusions.

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

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

No annotations exist, so the description carries the full burden and does well: it discloses return contents, that x-loutre-* headers are honoured, that latency is not awaited but reported as delayMs, and that writes are conditionally persisted. It omits auth/permission behavior and error semantics, keeping it from 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?

Three compact sentences with zero preamble; the core call-and-return contract is front-loaded and GraphQL/persistence caveats follow. Slightly dense but every sentence carries information an agent needs.

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 tool with no output schema and no annotations, the description covers return values, header semantics, GraphQL usage, and write persistence. Missing auth context (though schema covers accessKey/ownerToken) and error/failure behavior are the remaining 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 86%, so baseline is 3; the description adds real meaning beyond the schema by specifying the GraphQL body shape ({query, variables}) for POST, and by naming the honoured x-loutre-* headers that map to the headers parameter. This is substantive parameter-level guidance not present in 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 ('Call a route of the mock like an HTTP client would') plus the return shape (status, x-loutre-* headers, body). It does not explicitly differentiate itself from the sibling replay_request, which is the one tool whose purpose could plausibly overlap.

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 description: it explains GraphQL invocation via POST and that writes persist when persistent state is on. But it never says when to prefer this over siblings like replay_request or get_requests, nor any exclusions or prerequisites for calling 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?

With no annotations, the description carries the full burden, and it omits critical behavior: that the operation is destructive and irreversible, whether the log is per-mock or global, whether an owner token is required for authorization, and what is returned. Only the word "Empty" hints at data loss.

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; nothing is wasted or buried.

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, unannotated, no-output-schema tool, this is insufficient: it never says the clearing is irreversible, whether it is scoped to the slug's mock alone, or what happens if the mock doesn't exist. The agent has little to reason about beyond the verb.

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% — the slug pattern, example, and the ownerToken parenthetical are all documented in the schema, so the description adds nothing and is not required to. 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 states a specific verb ("Empty") and resource ("the mock's request log"), so the agent knows exactly what it does. However, it does not distinguish itself from nearby siblings like clear_rules, get_requests, or reset_state, which touch closely related state.

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 the alternatives: no mention of reset_state (which may clear more), clear_rules (which touches rules, not requests), or get_requests (read before clearing). 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?

No annotations exist, so the description carries the full burden. 'Every' hints at bulk deletion, but the description never states that the action is irreversible, whether it errors when no rules exist, whether the route itself is preserved, or that ownerToken may be required for authorization.

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 verb and the scope arrive immediately. It is efficient, though the terseness leaves no room for the caveats a destructive tool needs.

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, annotation-free tool with no output schema, the description should say what survives the call, what happens on an empty rule set, and whether the ownerToken is required. None of that is present, leaving a meaningful gap for a deletion operation.

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

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

Schema description coverage is 100%, with slug, route, and ownerToken all documented in the schema, so the baseline of 3 applies. The description adds only that 'route' scopes the operation to a single route's rules, which is marginal but consistent with 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 gives a specific verb ('Remove') plus resource ('every conditional rule of a route'), making the bulk-delete semantics explicit via 'every'. It implicitly distinguishes itself from the sibling add_rule, but never names a sibling or clarifies the boundary with clear_requests or delete_mock.

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 or when-not-to-use guidance is offered beyond the bare action. The agent is left to infer that this is the counterpart to add_rule and that clear_requests (a sibling) affects a different resource entirely.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the return payload (URL, route list, ownerToken), the seven-day lifetime without an account, the six-hour re-read for URL sources, and format-specific data handling (HAR headers/cookies dropped, db.json records served as-is, generated data coherent and generated once). Gaps remain around failure modes for invalid documents, auth requirements, and rate limits, which keeps 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?

The core action is front-loaded, which is good, but the format enumeration is a single sprawling sentence with deeply nested parentheses that is hard to parse and could be compressed or bulleted. The trailing sentences about return value, data generation and lifetime are tight and earn their place, partially offsetting the 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?

For a six-parameter tool with no output schema, the description compensates well by describing the return value, the mock lifetime, and the refresh behavior of URL-sourced mocks. The notable omission is that all six parameters are optional and the description never states that at least one of `spec` or `url` must be supplied, nor what happens when neither is given.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, and the description largely restates those semantics (spec vs url, auto re-read, slug being Pro-only, locale). The one addition of value is the six-hour refresh cadence tied to `url`, but that is behavioral rather than parameter-level meaning, so the baseline of 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?

Opens with a specific verb and resource ('Create a hosted mock') and immediately enumerates the accepted source formats, so the agent knows exactly what the tool produces. It is unmistakably distinct from siblings like get_mock, list_mocks, regenerate_mock or sync_mock, which operate on already-existing mocks.

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 creation verb and by the explicit spec-vs-url fork ('Give the document in `spec`, or its public address in `url`'), which is genuine routing guidance. However, no sibling is named as an alternative and no exclusion is stated (e.g., when to use regenerate_mock or sync_mock instead of creating a new mock), so the agent must infer that this is the 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?

No annotations are provided, so the description carries the full burden. It does disclose two important traits: the operation is irreversible ('Permanently') and it cascades to the kept schema. However, it says nothing about authorization needs (ownerToken vs connected account), failure modes, 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 front-loaded sentence with zero filler. The most decision-relevant word, 'Permanently', appears first.

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

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

For a two-parameter destructive tool with no annotations and no output schema, the description covers the core effect and collateral deletion but omits the return behavior and permission context. It is adequate but leaves gaps an agent would notice when handling results or auth.

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

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

Schema description coverage is 100%, with slug and ownerToken both documented, including the conditional note that ownerToken is not needed with an API-token connection. The description adds no parameter-level meaning beyond the schema, so baseline 3 applies.

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

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

The description states a specific verb and resource ('Permanently delete a mock') plus a scope detail ('and its kept schema'), which clearly separates it from create_mock, get_mock, and list_mocks. It does not explicitly name a sibling it must not be confused with, so it falls just 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 guidance on when to choose this over alternatives such as clear_requests, reset_state, or regenerate_mock, and no prerequisites or preconditions are stated. The only usage signal is the adverb 'Permanently', which implies cleanup/removal but leaves the agent to infer 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the return contents, including routes, behaviour, lock, and sample generated bodies, but does not mention read-only nature, authentication requirements, or error behavior.

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

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

The description is a single front-loaded sentence with no wasted words. Every listed item contributes to understanding what the tool returns.

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

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

For a simple read tool with fully documented parameters and no output schema, the description adequately enumerates the return contents. It could be more complete by noting authentication or usage context, but the core retrieval behavior is covered.

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

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

Schema description coverage is 100%, so the schema already documents both slug and ownerToken. The description adds no parameter-specific meaning beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description identifies the resource and enumerates the returned details: routes, identifiers, behaviour, lock, and sample bodies. It is clear what the tool retrieves, though it does not explicitly contrast itself with siblings like list_mocks or get_requests.

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 guidance on when to use this tool versus alternatives such as list_mocks or get_requests. Usage is only implied by the tool name and the phrase 'Details of a mock'.

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 real work: it discloses ordering (most recent first), the truncation behavior (body cut at 8 KB), the exact fields returned, and the replay id. It does not state read-only/side-effect profile, auth expectations, or how many requests are retained, which are meaningful gaps for an unannotated tool.

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

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

One tightly-packed sentence with the resource and ordering front-loaded, followed by a colon-delimited field list where each item earns its place. Slightly list-heavy but no filler.

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

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

No output schema exists, so the description must describe the return value — and it enumerates method, path, query, status, headers, body, answer source, latency, plus the id. Missing only limit/pagination behavior and retention/auth nuances, which are secondary for a 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?

Schema coverage is 67%; slug and ownerToken are documented in the schema and need no repetition. However, the 'limit' parameter has no schema description and the description does not compensate by explaining its default, cap, or effect on the result set — the one place the description could have added unique 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 resource (requests received by the mock) and ordering (most recent first), which is clearly distinct from siblings like clear_requests, get_mock, or list_mocks. It never names an alternative explicitly, but an agent can identify the resource without opening the schema.

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 clearly implied: inspect captured traffic, and the note that each entry carries an id for replay_request establishes the workflow link to that sibling. There are no explicit exclusions (e.g. how this differs from clear_requests or when to prefer list_mocks), which keeps it below 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?

With no annotations, the description carries the full burden; it does usefully disclose the auth requirement ('API token required') and the shape of returned fields. It says nothing about ordering, pagination, or whether all mocks or only active ones are returned, which matters 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?

A single front-loaded sentence: verb and scope first, then the auth caveat, then the returned fields. Every clause adds information and nothing is 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 zero-parameter read tool with no output schema, the description covers what is listed, what comes back, and the auth prerequisite. Only minor gaps remain around result ordering and result-set boundaries.

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; nothing in the schema needs interpretation and the description does not misrepresent any inputs.

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?

Specific verb+resource ('List ... mocks') scoped to 'the connected account's', plus the fields returned (URL, routes, expiry). It is clearly distinguishable from get_mock (single item) by the implicit 'all mocks' scope, though no sibling is 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?

Usage is implied: use it to enumerate the account's mocks, and an API token is required. There is no explicit statement of when to prefer get_mock or how this differs from other read tools like get_requests, leaving the routing to inference.

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

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

No annotations exist, so the description carries the full burden. It does disclose an important destructive side effect ('A full new set forgets persisted writes'), which is real value. However it doesn't say whether a route-scoped regeneration also discards persisted writes for that route, nor what the response contains, leaving gaps on a mutation tool.

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

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

Two short sentences, front-loaded with the action and then the side effect. Slightly dense phrasing ('for one route and the routes sharing its collection') but no wasted 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?

Five parameters, no annotations, and no output schema mean the description should say more about scope-dependent behavior (does route-level regeneration drop writes?) and return values. It covers the headline behavior but not the full decision surface.

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%, and the schema already explains slug, routeId, locale, and ownerToken. The description only adds that a new seed is generated (implying the seed parameter) and that a full set discards writes; the interplay between seed and routeId is not clarified.

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 action ('Generate a new data set (new seed)') and its scope: the whole mock, or one route plus routes sharing its collection. It's clear what the tool does, though it doesn't explicitly name the closely related siblings (reset_state, sync_mock) it differs from.

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 scope sentence implies when to pass routeId versus omitting it, but there is no explicit 'use this instead of reset_state/sync_mock when...' guidance. With several similarly-named state-manipulation siblings, an agent is left to infer which one regenerates 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?

With no annotations, the description does real work: it discloses that method, path, headers and body are replayed verbatim and evaluated against current (not historical) mock state, and that a response is returned. It is silent on whether the replay is itself recorded in the request log, whether it mutates state, and whether it can fail if the mock changed incompatibly — meaningful gaps for a no-annotation 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 sentences, zero filler, with the core behavior front-loaded and the usage hint trailing. Every clause 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?

No output schema exists, yet 'return the answer' is the only hint about the return value — an agent can't tell whether it gets the raw mock response, a status/wrapper object, or the matched rule. Combined with the unaddressed question of whether replays pollute the request log, the definition is workable but incomplete.

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

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

Schema description coverage is 100% and all three parameters (id, slug, ownerToken) are documented in-schema, including the get_requests provenance and the API-token auth exception. The description adds nothing parameter-specific, so baseline 3 applies.

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

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

States a specific verb (replay) plus the exact resource and scope: a logged request replayed byte-for-byte against the mock's *current* configuration. That 'as it is now' qualifier distinguishes it conceptually from call_mock, though no sibling is 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?

'Useful after changing a rule, a body or a scenario' gives a concrete triggering situation, and the schema notes the id comes from get_requests, implying the prerequisite workflow. No when-not guidance or named alternatives, so it stops short of 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?

With no annotations, the description carries the full burden. It usefully discloses that the operation discards persisted writes and reverts collections to a generated state, implying a destructive reset. However, it omits whether the reset is recoverable, whether it also affects rules/requests/access settings, and any auth requirements (ownerToken).

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 dense sentence with the effect front-loaded and no filler. Every clause (verbs covered, resulting state) 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 destructive state-reset with no annotations and no output schema, the description covers the core effect but leaves gaps: no mention of irreversibility, permission/auth needs, or how it interacts with other state (rules, requests). 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 coverage is 100% with both parameters documented in-schema, so baseline 3 applies. The description adds no parameter-level detail about slug or ownerToken beyond what the schema already provides.

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

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

States a specific verb ('Forget') and scope (persisted writes across POST/PUT/PATCH/DELETE), and clarifies the resulting state (generated collections revert). It distinguishes itself from narrower clears by covering all mutating verbs, though it doesn't explicitly name siblings like clear_requests or clear_rules.

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

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

The description implies when you'd use it (to undo persisted writes and restore generated collections) but gives no explicit when-to-use/when-not guidance or named alternatives. An agent must infer the scenario from the effect statement.

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

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

With no annotations, the description carries the full burden, and it does add one real behavioral trait: the Pro plan requirement. However, for a mutation tool it omits reversibility (how to unlock, whether null origins clears the restriction), whether omitted fields are left untouched or reset, and what permissions/ownership are needed beyond what the schema says.

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 effect and followed by the plan constraint. Nothing is wasted and nothing important is buried.

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 mutation with no annotations and no output schema, the description is thin: it doesn't state what the tool returns, whether the change is idempotent, or how omitted parameters are treated. The core effect and plan gate are present, so it is 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 75%, with slug, origins, and ownerToken already documented in the schema. The description only loosely maps "lock with a token (private)" to the private/ownerToken pair and says nothing about the semantics of the undocumented `private` boolean or partial-update behavior.

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

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

Names a specific verb (lock/restrict) and resource (mock) plus the two things being set: private token access and allowed browser origins. This distinguishes it reasonably from siblings like set_domain, set_behavior, and set_response, though it 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?

The "Pro plan" note is a useful prerequisite, but there is no explicit statement of when to use this versus set_domain or set_behavior, and no indication of when-not to use it (e.g. downgraded accounts, already-locked mocks). Usage is only implied by the described effect.

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 must carry the safety profile, and it does disclose mutation semantics: keys merge rather than replace, and null deletes settings. That is meaningful behavioral context. It omits other traits an agent would want: that this is an irreversibly mutating live-mock operation, whether omitted fields in a routes entry are preserved or reset, and any auth requirement, and it also partially repeats the merge note already present in the patch 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 sentences, zero filler. The scope enumeration is front-loaded and the merge rule follows as the one non-obvious caveat, which is exactly the right ordering.

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 schema is rich and nested, so most parameter detail is covered, and the description correctly complements it with merge semantics. But for an unannotated mutation tool with no output schema, it says nothing about what is returned, what happens on a non-existent slug, or the owner-token path, leaving real gaps in the overall 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?

Schema description coverage is 100%, so the nested patch fields, ranges, and null-vs-absent semantics are already documented in the schema. The description's field list mirrors those keys without adding syntax or format detail (e.g., route identifier form, scenario bundle shape) beyond what the schema states. Baseline 3 applies.

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

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

States a specific verb ('Change') and resource ('a mock's behaviour') and then enumerates the exact knobs affected: status, latency, jitter, error rate, persistent writes, per-route status/bodies/rules. That is far more specific than the name alone. It stops short of naming sibling tools (set_response, add_rule, reset_state), so the boundary with those is left implicit.

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

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

The merge semantics sentence ('missing keys are kept, null clears') is a genuine usage instruction for partial updates and hints at how to clear a setting. However, there is no statement about when to prefer this over add_rule for rules or set_response for bodies, nor any prerequisite note about needing an owner token or a pre-existing mock.

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 a good job: it discloses the external side effect (declares the record at Cloudflare), the destructive null-removal path that an agent would otherwise not anticipate, the Pro entitlement gate, and the auth nuance around ownerToken. It stops short of saying whether removal is reversible or what happens on DNS conflicts/invalid input.

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 dense sentence with the capability front-loaded, followed by the mode-selection clause. Every clause earns its place — plan tier, side effect, return value, and the three hostname modes — with no filler.

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

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

For a 3-param tool with no annotations and no output schema, the description covers purpose, side effects, return shape, plan gate, and mode semantics. The remaining gap is failure behavior (EligibilityError, DNS validation) which the agent may need before invoking.

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 schema already documents the tri-state hostname semantics ('null removes; omitted re-checks the status'), so the description's restatement adds little. Its marginal value is tying the modes to concrete outcomes (returns the CNAME to create vs. re-checking status), which is a modest addition over structured data.

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 — serves the mock under the account's own hostname via Cloudflare — and additionally names what it returns (the CNAME hostname → target plus status). No sibling in the list (set_access, set_behavior, set_response, create_mock…) touches custom hostnames, so the tool is unambiguously identifiable.

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 spells out the three invocation modes and when each applies: with a hostname to declare it, without hostname to re-check status, and with hostname null to remove it. Also flags the Pro-plan prerequisite. Lacks any when-not-to-use or dependency/precondition guidance (e.g. whether the mock must already be synced).

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

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

With no annotations, the description carries the full behavioral burden. It discloses that this is a mutation and that null restores the generated response, but it omits important details such as overwrite semantics, auth/ownerToken requirements, and what happens when the route or status does not exist.

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

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

The description is a single front-loaded sentence with no filler. Every clause contributes: the core action, the hand-written qualifier, and the null-body restore behavior.

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, this is under-specified. The description does not cover authorization via ownerToken, whether existing responses are overwritten, error behavior, or how status and route interact with generated responses.

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 most parameters. The description repeats the null-body behavior that is already present in the schema for body, and adds little meaning for slug, route, status, or ownerToken.

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: setting the JSON body a route returns for a given status. It is clear what the tool does, but it does not distinguish this from neighboring tools such as set_behavior or add_rule, which likely also alter route responses.

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 'hand-written response' and the note that a null body restores the generated response imply when to use it, but they do not explicitly say when to use this instead of add_rule or set_behavior. 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?

With no annotations, the description carries the full burden, and it does disclose the key state consequences: settings are kept and persisted writes are forgotten. That is exactly the risk an agent needs to know before calling a mutating sync. It still omits failure behavior when the source URL is unreachable and whether request logs are touched.

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 dense sentence that front-loads the action and tucks the state consequences into a parenthetical, with force addressed last. Efficient, though the parenthetical packs two distinct ideas (settings kept, writes forgotten) into one clause.

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 action, the change scope, state preservation, and the force parameter. The remaining gap is error/recovery behavior when the remote document cannot be fetched, which matters for a network-dependent sync.

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%; slug and ownerToken are already documented in the schema, and the description supplies the missing semantics for force (regenerate even when unchanged). That is real added meaning beyond the schema, though it does not clarify how force interacts with the "only if changed" default in edge cases.

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: re-read the source schema and update the mock if changed, with the scope of what is refreshed (routes, fields). It is clear what the tool does, but it does not differentiate itself from the sibling regenerate_mock, and the phrase "force regenerates" in the same breath blurs the boundary between the two.

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?

"Re-read ... now" and "force regenerates even when the document is unchanged" imply when to use the default path versus the force path, so usage is inferable. However, there is no explicit when-not guidance and no mention of regenerate_mock as the alternative for the overlapping case.

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