Locus

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds the useful precondition that only *unused* quotes can be cancelled, implying already-executed approvals are unaffected, but says nothing about irreversibility, error conditions, or token validity beyond that.

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

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

One short sentence with no filler and the condition ('unused') front-loaded alongside the verb. Its brevity is efficient, though the same brevity contributes to the completeness gaps noted elsewhere.

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 is destructive but carries annotations and an output schema, so the safety and return-value burden is largely handled elsewhere. Still, an agent gets no guidance on when cancellation is permitted or what happens to the estimate afterwards, which matters for a destructive 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 coverage is 100% and the single parameter is fully described in the schema as an 'estimate_cost token'. The description adds no format, origin, or lifetime detail beyond what the schema provides, so the baseline 3 applies.

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

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

The description gives a verb ('Cancel') and an object ('an unused executable quote'), so the action is identifiable. However, the object wording ('quote') does not match the tool name ('cost approval'), leaving ambiguity about whether a quote and an approval are the same entity. There is no differentiation from siblings like estimate_cost or execute.

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 word 'unused' hints at a precondition, but there is no explicit statement of when to call this tool versus letting an approval expire or re-running estimate_cost, and no mention of alternatives. Guidance is essentially absent.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed-world boundary, so the safety profile is covered. The description adds useful content disclosure (schema, example, output shape, price) but says nothing about rate limits, auth requirements, or the pagination/search behavior implied by the cursor and query parameters.

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 that enumerates the returned artifacts compactly. It is appropriately sized, though extremely terse for a five-parameter tool.

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

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

An output schema exists, so return values need no explanation, and annotations cover safety. However, the description omits usage context and leaves the four optional search/pagination parameters unexplained, so it is only just sufficient for a tool whose parameter set implies more than 'describe one endpoint'.

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

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

Schema description coverage is 100%, so the baseline of 3 applies; each parameter has at least a short description in the schema. The description adds no parameter meaning at all and does not clarify the non-obvious role of model_cursor, operation_query, and operation_offset, which suggest this tool also browses models/operations.

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

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

States a specific verb ('Get') and resource ('one endpoint') plus the exact payload: schema, example, output shape and price. This distinguishes it from the plural search-oriented sibling search_apis, but the description never names that sibling or any other, so differentiation is inferred rather than stated.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as search_apis (to find an endpoint) or execute (to run it). The agent must infer that this is an inspection step before execution.

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 readOnlyHint=false, idempotentHint=false and openWorldHint=true, but the description adds nothing about what state a "quote" creates, whether anything is charged or reserved, or how the returned quote relates to a later execute. A word like "Quote" naturally reads as read-only, so the non-read-only annotation deserves explicit explanation that the description does not provide. No hard contradiction is present (the idempotency_key shared with execute implies server-side quote state), but the gap is significant.

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 nine-word sentence with zero filler, front-loading the action and the modifier. It is efficient, though it reads more as a fragment than a structured statement given the tool's complexity.

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 nine-parameter, open-world, nested-object tool with an output schema and non-idempotent, non-read-only semantics, a single terse sentence is far too thin. It omits what quoting entails, how the ceiling is enforced, what preflight_external_quote does, and how the quote is consumed by execute. The output schema covers return values, but the workflow-critical context is missing.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters, including the ceiling (max_charge_credits), the slug-vs-provider+endpoint alternative, and the preflight probe. The description's "optional charge ceiling" merely echoes one schema field and adds no syntax, format, or constraint detail beyond it. 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 an action ("Quote request body") plus an optional modifier ("charge ceiling"), which loosely matches the tool name estimate_cost. However it never names the resource being priced (a paid/x402 endpoint call) or the unit of estimation, so the purpose is implied rather than stated. It is differentiable from execute only by inference from the name, not from the description text.

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

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

There is no when-to-use, when-not-to-use, or alternative routing guidance. The obvious relationship — estimate before calling execute — is never mentioned, nor is the role of preflight_external_quote. The agent must guess the workflow from the schema 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 destructiveHint=true, openWorldHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds the single most important behavioral fact not in annotations: this call charges credits, plus that only 'enabled' endpoints may be invoked. It stops short of explaining failure/refund or approval behavior, but that is a meaningful add against an annotated baseline.

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

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

A single front-loaded sentence with no filler; the core action leads and the cost warning follows. It is efficient, though for a credit-charging, destructive tool it sits close to under-specified rather than optimally sized.

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?

An output schema exists, so return values need not be described, and the schema carries all six parameters. However, for a destructive, fund-consuming, open-world tool with nested objects, the description leaves the surrounding workflow (estimate_cost quote, approval_token/idempotency_key interaction, retry consequences) to be inferred from other tools.

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

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

Schema description coverage is 100%, with slug, args, loop_id, attribution, approval_token, and idempotency_key all documented in-schema, including the retry/idempotency and cost-quote semantics. 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?

States a specific verb (call/execute) and resource (an endpoint), and pins the discovery path by naming the sibling search_apis. It is clearly distinguishable from discovery siblings, though it does not differentiate itself from other execution-adjacent siblings such as describe_api, estimate_cost, or get_call_result.

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 clause 'found via search_apis' implies the prerequisite discovery step and 'enabled' implies a gating condition, so usage is partially implied. There is no explicit routing advice (e.g., when to use estimate_cost first or how to handle the approval_token flow), so alternatives are not addressed.

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

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

The annotations already establish read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description does add genuine non-duplicative context: that secret-key auth can target either an end user or the pooled account. However, it does not explain what a missing key or a non-secret key does, which is the behavior an agent would most need.

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

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

Two short sentences, verb-first, with no filler. It is arguably over-terse, but nothing wasteful is present.

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

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

An output schema exists, so return values need no explanation, and annotations cover safety. Still, for a tool whose result depends on auth mode, the description leaves the auth requirement and the meaning of "credits" (unit, scope) unstated.

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 external_user_id as an end-user id for secret-key auth. The description adds meaning the schema lacks: that omitting it can resolve to the pooled account, clarifying the optional parameter's semantics.

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

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

"Get credits" names a verb and a resource, but the resource is stated as "credits" while the tool is get_balance, leaving the agent to infer that this returns a credit balance. It gives no differentiation from billing-adjacent siblings such as estimate_cost or cancel_cost_approval.

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 call this versus another tool, and no prerequisites beyond an oblique mention of secret keys. The agent must infer that this is the tool for checking remaining credits rather than a cost-estimation path.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds the key behavior that results are read in chunks, but it does not elaborate on async waiting or pagination continuation semantics beyond what the schema descriptions provide.

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

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

The description is a single front-loaded sentence with no wasted words. It communicates the core action, scope, and retrieval mode efficiently.

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?

An output schema exists, so return values need not be explained, and the parameter schema is fully covered. The description states the chunked-read purpose, though it could better connect the receipt ID back to the originating execute workflow; nevertheless, it is largely complete given the rich structured metadata.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter syntax or selection guidance beyond mapping receipt ID to api_call_id and implying chunked access via page/offset/max_characters, all of which the schema already documents.

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: reading a call result, scoped to long results retrieved in chunks by receipt ID. It is clear enough to distinguish from list/execute siblings by its 'receipt ID' and 'chunks' focus, though it does not explicitly name a sibling 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 implied: use this when you have a receipt ID and need to read a long result in chunks. However, it does not state when not to use it, nor does it explicitly route the agent to or from execute/list_calls, leaving the workflow context to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds only the trigger condition; it says nothing about that results are chunked via max_characters/cursor pagination or that a guide may be returned by task-matching, both of which are behavioral traits the schema alone implies rather than states.

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

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

A single front-loaded sentence with no filler, which is structurally sound. It is terse to the point of being under-specified rather than wasteful, so it earns a 4 rather than a 5.

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?

An output schema exists, so return-shape explanation is not owed, and 100% param coverage means the schema carries the argument burden. Still, for a 6-parameter, paginated, single-optional-id fetch/list tool, the description leaves the core mental model (what a Locus guide is, when to prefer this over describe_api) unstated.

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 six parameters carry their own descriptions, so the baseline is 3. The description adds no meaning beyond that — it does not even hint at the list-vs-fetch duality (omit id to list, supply task to pick) which is the tool's most important parameter interaction.

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?

"Fetch Locus guides" gives a clear verb plus resource, and the qualifier "when native skills are unavailable" scopes it. However, "Locus guides" and "native skills" are never defined, so an agent unfamiliar with the platform cannot tell what content is actually returned or how this differs from documentation-oriented siblings like describe_api.

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 "when native skills are unavailable" is a genuine usage condition, but it is the only one and is never unpacked — there is no statement of what "native skills" means, no fallback ordering, and no alternative tool named for the case where a skill is available.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered externally. The description adds nothing beyond that: it does not mention pagination behavior (despite cursor parameter), default limits, or what status='all' implies. With annotations present the bar is lower, but this adds essentially no behavioral context.

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?

Very short, only one sentence, but the brevity comes at the cost of missing information rather than being efficiently front-loaded. It is not bloated, but it is under-specified.

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?

An output schema exists, so return values need not be explained. However, with four optional filter parameters and pagination via cursor, an agent needs at least a hint about filtering, result shape, and relationship to status/provider. None is provided, making the definition insufficient for correct invocation in a large tool set.

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 itself documents limit, cursor, status, and provider. The description adds no parameter meaning or filter syntax beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description 'List your recent calls' restates the tool name (list_calls) and title (List calls) with only a vague modifier 'recent'. It does not clarify what a 'call' is (API call? phone call? model call?) in a context full of workflow and cost-related tools, and it gives no way to distinguish this tool from siblings.

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

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

No usage guidance at all. There is no indication of when to use this tool versus alternatives, no mention of filtering behavior, and no reference to any sibling tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one genuine behavioral fact beyond annotations, that browsing does not enable the tools, but says nothing about pagination behavior (cursor/limit) or scope of results.

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 eight-word sentence, front-loaded with the action and resource, with the negative clarification attached efficiently. Nothing is wasted, though the extreme brevity leaves it closer to terse than complete.

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 an output schema present, return values and pagination structure need not be re-explained, and annotations cover the safety profile, so the description is not required to carry much. Still, it offers no usage routing or context on what a 'pack' or 'category' means, leaving gaps for an agent choosing among discovery tools.

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

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

Schema description coverage is 100%, so all four parameters (kind, limit, query, cursor) are already documented in the schema; baseline 3 applies. The description's mention of 'categories and packs' loosely maps to the kind enum but adds no syntax or format detail beyond the schema.

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

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

States a specific verb (browse/list) and a concrete resource (executable categories and packs), so an agent knows this enumerates tool groups rather than invoking them. It does not name or distinguish itself from any sibling such as search_apis or list_calls, so it stops short of a 5.

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

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

The clause 'does not enable tools' implicitly steers the agent toward discovery-only use and away from activation workflows, which is useful implied guidance. However, it names no alternative tool and gives no explicit when-to-use/when-not conditions, so it remains at the implied-usage level.

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

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

Annotations already declare the safety profile (readOnly=false, idempotent=true, destructive=false), so the bar is lower, and the description adds a genuine behavioral trait: the first pin requires explicit context-cost acknowledgement. That prerequisite is not encoded in the annotations and materially changes how the agent must call the 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 tight sentences with no filler, and the more consequential constraint (first-pin acknowledgement) is placed second but still reads as a compact caveat. Every sentence earns its place.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description supplies the one non-obvious prerequisite, leaving only minor gaps such as the effect of unpinning on existing connections.

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 slug, pinned, and acknowledge_context_cost thoroughly. The description restates the acknowledgement requirement at a conceptual level but adds no new syntax or format detail beyond what the schema provides; baseline 3 is appropriate.

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

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

The description gives a specific verb pair (add or remove) and resource (one enabled endpoint as a typed tool on workspace MCP connections), which is far from a tautology of the name. It does not explicitly contrast with a sibling, but no sibling competes for the same pin/unpin action, so disambiguation is largely moot.

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 implies when the tool applies (pin/unpin of an enabled endpoint) and surfaces a prerequisite for first use, but never states when to reach for this tool over alternatives or any conditions that would steer an agent away. Guidance remains implied rather than explicit.

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 readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the agent knows it is a non-destructive, non-idempotent submission confined to Locus. The description restates the action and adds nothing behavioral, such as whether reports are persisted, throttled, or tied to a call. No contradiction with 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?

A single short sentence, front-loaded with the action and destination, with no filler. It is efficient, though borderline under-specified rather than wasteful.

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?

An output schema exists, so return values need not be explained, and the schema covers all parameters. However, for a submission tool the description gives no context on when a report is appropriate or how the optional tool/call_id/context fields should be used to make the report actionable.

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 four properties (tool, call_id, context, message) are already documented in the schema. The description adds no parameter meaning beyond that, which is the expected baseline when the schema carries the load.

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

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

"Report a bug to Locus" names a verb (report) and a resource (bug), so the basic action is decipherable, but it adds almost nothing beyond the tool name and title, and provides no differentiation from the large set of sibling tools. It is minimally viable rather than specific.

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, what conditions warrant filing a bug versus e.g. retrying a failed call, or whether prerequisites apply. The single sentence offers no usage context at all.

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 cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds real behavioral context beyond them: the link is short-lived and requires human approval, so the agent understands this is an asynchronous, human-in-the-loop request rather than an immediate grant. It stops short of saying what happens after approval or whether auth/ownership is 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 sentence with no filler, and the most important information (what is created) is front-loaded before the scope qualifier.

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

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

With one well-documented parameter, populated annotations, and an output schema to carry return values, the description supplies enough. The missing piece is the post-approval workflow (what the agent or user does next), which would make it fully complete.

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

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

Schema description coverage is 100% and the single slug parameter is fully documented as 'Exact provider/endpoint slug returned by search', so the schema carries the burden. The description reinforces the single-endpoint scope but adds no syntax or format detail beyond the schema.

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

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

States a specific verb and artifact ('Create a short-lived human approval link') and narrows the scope to 'one disabled catalog endpoint', so an agent knows exactly what the tool produces and how many resources it targets. It does not name a distinguishing sibling, which keeps it 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?

The phrase 'for one disabled catalog endpoint' implies the precondition (the endpoint must be disabled and looked up first), but usage is only implied. There is no explicit when-to-use, no statement that this does not itself grant access, and no mention of alternatives such as execute or cancel_cost_approval.

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 readOnly=false, idempotent=false, destructive=false, and openWorld=true, so safety is partly covered. The description goes beyond that by disclosing that this is a live billed request, that credits charged are reported in the result, that no model runs on the path, and that results are capped at ten with deterministic merging — all material behavioral facts an agent cannot get from the annotations alone.

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

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

Two sentences with no filler, and the core behavior is front-loaded. The prose is dense with internal pipeline jargon ('Perplexity-high + Parallel-basic fan-out'), which is compact but not immediately parseable.

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?

An output schema exists, so return structure needn't be described. However, for a 17-parameter tool with low schema coverage and only one required field, the description omits guidance on the legacy fields, mode selection, and provider/credits tradeoffs, leaving an agent to infer too much from the schema alone.

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 17 parameters and only 41% schema description coverage, the description carries a real compensation burden but adds almost nothing parameter-specific. It never explains mode, providers, rails, strategy (even that the latter two are legacy), maxCredits, or the domain filters; the only loose mapping is 'ten-result cutoff' to the maxResults default.

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 ('Find sources') and then exposes the pipeline (fan-out, deterministic merge, dedup, lexical reranking, ten-result cutoff). 'No Locus-controlled model runs on this path' subtly distinguishes it from a model-backed research path, though it never names the sibling web_research, which would have made the boundary 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?

There is no stated when-to-use or when-not-to-use guidance and no explicit alternative named, despite siblings web_research, web_extract, and search_apis being obvious candidates to disambiguate against. The only usage signal is the passing note that it is a 'live billed request,' which hints at cost-awareness but not tool selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact, the enabled-only default, but says nothing about result limits, ranking, or pagination beyond what the params already state.

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 that front-loads the default behavior before the exception. Every clause carries information and nothing is wasted.

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

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

An output schema exists and the params are fully described, so the description need not explain return values. It adequately covers the default filtering model for a zero-required-param search tool, with only minor gaps around result limits and how filters combine.

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 fully documents all 7 parameters including the enabled default and the cursor semantics. The description merely restates the enabled default, adding no format, syntax, or interaction detail beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ("Find ... catalog APIs") plus the default scope (enabled only) and what is returned (prices, access state). It is clearly distinct from siblings like describe_api or list_calls in tone, 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 clause "filter for disabled APIs" implies the main use case (broadening results), and the default hints at normal usage. However there is no explicit when-to-use/when-not guidance and no sibling tool is named as an alternative for a different filtering axis.

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 behavioral context beyond annotations: 'Live billed request; the result reports credits charged' explains why readOnlyHint is false for a content read, and the two-stage extractor/retry story sets reliability expectations. It does not mention idempotency behavior or caching, though those are covered by schema parameters and 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?

Three tight sentences, front-loaded with the core action and scoping constraint, then the billing warning. No filler, though the extractor-retry sentence is closer to implementation detail than decision-relevant guidance.

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

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

With an output schema present, return values needn't be described, and the description covers the key non-schema concerns: exact-URL-only scope, live billing, and credit reporting. It omits any mention of caching (maxAgeSeconds) or retry idempotency, which are minor given the schema's per-parameter docs.

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 89%, so the schema already documents urls, json, objective, maxCredits, maxAgeSeconds and the _locus controls in detail. The description adds only indirect meaning (cost is charged, no URL substitution) and no syntax or format guidance beyond the schema. Baseline 3 applies when the schema carries the parameter burden.

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 (read/extract) and resource (the exact public URLs supplied by the caller), and explicitly contrasts its behavior with discovery ('never searches for substitutes'), which cleanly separates it from router_web_search and web_research without needing to name them.

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

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

Gives a clear precondition (you must already have the exact URLs) and an implied exclusion (no search/substitution), so an agent knows this is not a discovery tool. It never names a concrete alternative tool for the discovery case, so the routing guidance stops just short of explicit.

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, openWorldHint=true, idempotentHint=false, so the safety profile is covered. The description adds genuinely new context the annotations cannot convey: the request is live-billed and the result reports credits charged, which is essential for a cost-aware agent calling a paid 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?

Three tight, front-loaded sentences: the capability comes first, then tier selection, then billing disclosure. No filler, though the effort sentence sits awkwardly against the competing mode enum and could be sharper.

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 19-parameter tool with nested objects, legacy-retained fields, and a required-dependent-parameter relationship (outputSchema requires effort), the description is far too thin. It leaves an agent unable to decide between this and router_web_search, and says nothing about the credit-ceiling parameter that governs the very billing it advertises.

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 roughly 47% schema description coverage across 19 parameters, the description needs to compensate, and it does not. It only names the effort tiers (light/medium/heavy), and it conflates this with 'mode' by saying 'choose light, medium, or heavy effort' when mode uses a separate fast/balanced/comprehensive enum; maxCredits, maxResults, topic, recencyDays, domain filters, and the legacy rails/strategy fields go entirely unaddressed.

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 outcome: a grounded, current answer with inline source references, which distinguishes it from web_extract's raw-page retrieval. However, it never differentiates itself from the sibling router_web_search, which an agent would plausibly consider interchangeable, so sibling disambiguation is missing.

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?

Offers effort-tier guidance (light/medium/heavy) which implies when to reach for a heavier, more expensive run, but gives no explicit when-not conditions and no routing advice against router_web_search or web_extract. Usage is only implied, not stated.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false. The description adds a meaningful behavioral constraint — saving requires a successful check of the exact revision — but does not cover permissions, archive side effects, or retry behavior beyond the idempotency annotation.

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 list and then the key revision-check constraint for save. No redundancy, and details correctly live in the rich schema rather than being repeated in the description.

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

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

Output schema exists, annotations cover the safety profile, and schema descriptions cover all parameters. The description supplies the high-level action set and the critical revision requirement for save, though it omits action-level prerequisites that are handled by the schema.

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

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

Schema description coverage is 100%, so all 14 parameters are already documented in the schema. The description adds no parameter-level meaning beyond noting that saving requires a successful check of the exact revision; the baseline of 3 is appropriate.

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

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

The description enumerates the supported actions (list, create, update, inspect, clone, archive, save) and the resource (customer-owned Workflow code). Purpose is clear, but it does not name or explicitly distinguish this tool from siblings like workflow_validate or workflow_run.

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

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

No guidance is given on when to use this tool versus alternatives such as workflow_validate, workflow_run, or workflow_runs. The action enum in the schema implies the tool's scope, but the description does not state when-not to use it or which sibling to choose for validation versus execution.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, openWorldHint=true, and readOnlyHint=false. The description adds genuinely new traits not in the annotations: that the run is 'queued' (i.e., asynchronous submission rather than a blocking call) and bounded by a 'hard credit ceiling', which tells the agent cost is capped but a charge can still occur.

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

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

A single front-loaded sentence with no filler; the verb and the key scoping constraints (exact version, credit ceiling, isolated mode) all appear before any qualifiers. Nothing wasteful.

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?

Because an output schema exists, return values need not be described, and all parameters are schema-documented. Still, for a 9-parameter destructive, open-world submission tool, the description omits what happens after queuing (polling/retrieval via workflow_runs) and whether the credit cap rejects or truncates the run, 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 100%, so all nine parameters (including the mode enum, immutable version, mutually exclusive input/input_artifact_id, and credit cap) are already documented in the schema. The description adds no additional parameter syntax or constraint detail beyond what is structured, so the baseline 3 applies.

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

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

States a specific verb (queue a run) and resource (one exact saved Workflow version), with the scope qualifiers 'isolated pilot or production' and 'hard credit ceiling'. It clearly distinguishes a run-submission tool from siblings like workflow_validate, workflow_runs, and workflow_definition, though it doesn't name them.

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

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

The 'pilot or production' phrasing implies when to pick each mode, which is useful context. However, there is no explicit when-to-use/when-not guidance and no routing to alternatives (e.g., use workflow_validate first, or workflow_runs to inspect results), leaving the agent to infer the placement in the workflow lifecycle.

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

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

The description adds useful behavioral context beyond the annotations: call/artifact access avoids a new charge, cancel prevents new dispatch, and resume requires eligibility and current authorization. It does not contradict the destructiveHint or idempotentHint annotations, though it leaves some operational details to the annotations and 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?

The description is a single dense sentence that front-loads the main operations and contains little wasted text. The phrasing is somewhat packed, but each clause corresponds to a distinct supported action.

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 seven-parameter tool with an output schema and full schema description coverage, the description is complete enough to understand the action surface and key caveats. It could be stronger if it explicitly related this multi-action tool to the singular workflow_run 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 100%, but the description adds meaning to the action parameter by mapping enum values to concrete behaviors like paging stored provider-call responses or artifacts and resuming eligible runs. It does not elaborate on parameter formats, but the schema already documents those thoroughly.

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 specific verbs and resources for each supported action: list runs, get status, page provider-call responses or artifacts, cancel dispatch, and resume runs. It clearly identifies the tool as a multi-action workflow-run controller, though it does not explicitly distinguish itself from the sibling workflow_run or workflow_definition tools.

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

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

It gives contextual cues for several actions, such as paging stored provider-call responses or artifacts 'without a new charge' and resuming only an 'eligible run with current authorization.' It does not provide explicit when-not-to-use guidance or name alternative sibling tools for overlapping cases.

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 readOnlyHint=false, idempotentHint=false, destructiveHint=false and a closed-world scope, which already frame the safety profile. The description adds the pre-persistence framing and the no-network fixture isolation, but it does not disclose side effects such as artifact creation, and it largely echoes mode semantics already present in the schema.

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

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

A single dense sentence covering all three modes with the modes front-loaded per clause. It is efficient and front-loaded, though the compressed phrasing ('check inline source before persistence') is slightly elliptical.

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 an output schema present, return values need not be explained, and the description covers all three invocation modes plus the mutual-exclusivity contract. It is reasonably complete for a 5-parameter tool, with only minor gaps around side effects and sibling routing.

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 mode enum, source, revision, fixture_set, and workflow_id semantics are fully documented in the schema itself. The description adds only the high-level mode framing, so the baseline of 3 is appropriate.

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

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

The description conveys a specific verb+resource operation ('check inline source', 'check one exact draft revision', 'run fixtures') that aligns with the tool name, so an agent understands it validates workflows rather than running them. However, it never explicitly names the object being validated and does not distinguish itself from siblings like workflow_run or workflow_definition.

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 clear context for each of the three entry paths: inline source 'before persistence', one exact draft revision, or 'isolated no-network fixtures'. This effectively tells the agent which scenario maps to which mode, though it offers no explicit when-not-to-use guidance or named alternatives among siblings.

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