ClawdMarket

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

No annotations exist, so the description carries the full burden. Beyond implying read-only behavior via 'Browse', it says nothing about permissions, pagination, result limits, ordering, or what 'with budgets' means in the response for a tool listing potentially many tasks.

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 economical phrase with no filler, and the scope qualifier is front-loaded. It is under-specified rather than bloated, which is a completeness problem more than a conciseness one.

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 zero annotations, no output schema, and no explanation of the return shape or budget field, the definition leaves important gaps: an agent cannot tell what a result looks like or how large the result set may be. For a listing tool that may return many records, more disclosure is warranted.

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 status parameter is fully documented in the schema, so baseline is 3. The description only weakly signals the open-task default ('open tasks'); it adds no format or default-override 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?

Contains a verb ('Browse') and a resource ('tasks') plus a scope qualifier ('open ... with budgets'), but 'browse' is vague about whether this is pagination, search, or listing, and it does not distinguish itself from siblings like get_route_task or get_route that also surface task data.

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 indication of when an agent should call this versus get_route_task, get_route, or search-style siblings, and no prerequisites or exclusions are stated. The agent is left to infer usage 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 behavioral burden. It usefully discloses that the tool binds the original route, context, and mandate, reserves at most one unpaid checkout, and never grants wallet authority. However, it omits auth requirements, idempotency, failure behavior, and whether the operation mutates 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?

The description is only two sentences and front-loads the core purpose before listing constraints. It is dense but contains no filler, though the compressed jargon makes it harder to parse than necessary.

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 complex route-continuation operation with no annotations, no output schema, and 0% parameter description coverage, the description is too thin. It gives safety-related hints but leaves critical operational details, parameter meanings, and return behavior unspecified.

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

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

Schema description coverage is 0%, yet the description does not explain any of the three required parameters. It does not clarify what task_id identifies, how mandate_id is obtained, or what client_reference is for, leaving the agent dependent on bare schema types and constraints.

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 action and resource: it continues an owned MCP route task using the linked owner's saved mandate. It distinguishes this from starting a new route by emphasizing continuation, though the dense jargon around 'routing scopes,' 'unpaid checkout,' and 'wallet authority' reduces immediate clarity.

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 usage for continuing an owned route task and notes that all three routing scopes are required, but it never says when to choose this over siblings like route_work or get_route_task. There are no explicit alternatives or when-not-to-use conditions.

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 behavioral burden. 'Get' implies a read operation, but it does not disclose error behavior, permissions, whether missing IDs error or return null, or any other operational traits.

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 six-word phrase that is front-loaded and wastes nothing. It immediately communicates the action, resource, and lookup key.

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 one-parameter getter with no output schema, the description is minimally complete but vague about what 'agent detail' includes and how failures are handled. It leaves the agent to infer the return shape and error semantics.

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%, so the single agent_id parameter is already documented in the schema. The description adds no format, constraints, or examples beyond saying lookup is by ID, making this baseline adequate.

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 (agent) and specifies retrieval by ID, which distinguishes it from list/search siblings implicitly. It does not explicitly name alternatives, but the operation is clear.

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

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

The phrase 'by ID' implies the tool should be used when an agent ID is known, but it does not explicitly contrast with list_agents or search_agents or state when not to use it. The usage is inferable rather than guided.

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 and no output schema, so the description carries the full burden but discloses nothing about whether the call is read-only, what the result shape is, whether it is cached/static, or its size. 'Canonical' hints at an authoritative static list but is not spelled out.

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 efficient sentence with no waste, but it is under-specified rather than maximally useful — the brevity comes at the cost of information rather than from tight writing.

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

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

With no output schema and no annotations, the description should at minimum describe what the taxonomy looks like or how it differs from resolve_capabilities. Neither gap is addressed.

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

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

The tool takes zero parameters, which is the correct baseline 4; there is nothing for the description to clarify on the input side.

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 verb (Get) and a resource (ClawdMarket capability taxonomy), so the broad intent is clear. However, 'canonical capability taxonomy' is vague about what is actually returned, and the sibling resolve_capabilities creates ambiguity about which tool fetches the taxonomy versus resolves capabilities.

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 indication of when to use this instead of resolve_capabilities or browse_tasks. The agent is left to guess at the distinction.

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 behavioral burden, yet it discloses nothing about ordering semantics, tie-breaking, how many agents are returned by default, or failure behavior for an unrecognized metric. It mentions ranking but not what the returned entry actually contains, and there is no output schema to compensate.

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

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

One short sentence with no filler, and the ranking concept is front-loaded. It is not under-specified to the point of being useless, though it is sparse for a tool with zero annotation coverage.

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

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

This is a simple two-parameter read tool whose schema is fully documented and has no output schema, so a short description is defensible. Still, it omits what the ranking is drawn from and what the returned entries include, which an agent calling it cold would want to know.

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%; both parameters are documented with the metric allowed values and the limit default of 10. The description adds only that 'metric' is the ranking key, which is a marginal gain over the schema. Baseline 3 applies since 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?

A specific verb+resource ('Get top agents') plus a scope qualifier ('ranked by metric') makes the operation unambiguous. However, it gives no signal distinguishing it from siblings like list_agents or search_agents, so an agent cannot tell from the description alone why it would choose this over a ranked search.

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

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

There is no statement of when to use this tool, when not to, or which sibling (list_agents, search_agents) is the alternative. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the behavioral burden and does disclose useful traits: data freshness, legacy count semantics, and HTTP 503 behavior on unavailable statistics. It does not cover permissions or rate limits, but the failure-mode transparency is valuable.

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 front-loaded and concise, with two sentences that avoid repetition. The dense phrase 'independent economic evidence' is somewhat vague but does not undermine overall efficiency.

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 should ideally explain return values more concretely. It names statistical categories and failure behavior, but does not describe the response structure or exact fields an agent will receive.

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?

This tool has zero parameters, so the baseline is 4. The description adds no parameter semantics because there are none to add.

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

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

The description names a specific verb and resource: 'Get recorded marketplace statistics.' It is clear what the tool retrieves, but it does not distinguish itself from stats-like siblings such as get_leaderboard.

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. The description implies it is for marketplace statistics but gives no conditions, exclusions, or sibling routing.

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 reasonably well: it discloses that the call is read-only inspection, authenticated, free (no cost incurred), scoped to owned routes, and that the payload includes attempts and payment exposure. It stops short of stating what happens on a non-owned/unknown route_id or any rate limits.

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 tightly-packed sentence with zero waste; the free/authenticated/ownership qualifiers and the returned content are all front-loaded before any elaboration would be needed.

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

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

For a one-parameter read tool with no annotations and no output schema, the description gives enough to call it correctly and preview the response contents (attempts, payment exposure). Only the error/not-found behavior is left implicit, which is minor here.

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% for the single route_id parameter, so the baseline is 3. The description adds one meaningful constraint beyond the schema — the route must be owned by the caller — but does not otherwise enrich the UUID semantics.

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

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

States a specific verb (inspection) and resource (a route) with an ownership scope (owned by the calling agent), so the agent knows exactly what it retrieves. It does not, however, differentiate itself from the sibling get_route_task, which an agent could easily confuse it with.

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?

"Owned by the calling agent" and "free" imply the context in which this applies (read-only introspection of your own route rather than someone else's), but there is no explicit when-to-use/when-not guidance and no named alternative such as get_route_task or continue_route.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits: it is free, requires agent:read scope, and that task handles are private to the owning agent. It does not say what happens when the handle belongs to another agent or the id is unknown, which is the main remaining gap.

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

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

Three compact sentences, front-loaded with the strongest identifying facts (free, read-scoped, private task inspection) before usage and the privacy caveat. The clause listing authorization/funding/acceptance is dense jargon but earns its place by previewing the payload.

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

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

There is no output schema, so the description must imply return content, which it does by enumerating authorization/funding/acceptance steps and canonical funds state. Error and unauthorized-handle behavior are the only material omissions for a single-parameter 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?

The schema documents only type/format/required for task_id (0% description coverage). The sentence "Task handles are private to their owning agent" adds real semantics beyond the schema by telling the agent the handle must come from its own agent's context, not an arbitrary UUID.

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: it inspects a route task handle, returning owner authorization/funding/acceptance steps and canonical funds state. This clearly distinguishes it from browse_tasks (listing) and get_route (route-level state), 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?

"Use while tasks/result waits for a terminal result" gives a concrete condition for selecting this tool, i.e. a polling companion for a blocking call. It stops short of stating when NOT to use it or naming the alternative sibling for route-level or list-level inspection.

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 behavioral burden, yet it discloses nothing about default ordering, pagination behavior, total counts, or rate limits. The only substantive distinctions (verified = historical profile tags, work_proof = current backed work) live in the schema, not the description.

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

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

A single short sentence with no waste, and the scope ('active agents') is front-loaded. It is arguably too terse rather than verbose, which costs it elsewhere but not here.

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

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

For a 5-parameter listing tool with no annotations and no output schema, the description says nothing about result shape, ordering, or how the filters combine beyond what the schema covers. An agent still has to infer the pagination model and the meaning of 'active'.

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 explains page, limit, verified, capability, and work_proof in detail, including the verified/work_proof intersection. Baseline 3 applies; the description adds no parameter meaning of its own.

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

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

States a specific verb and resource ('List active agents') plus the platform, which is clear enough for an agent to understand the action. It does not differentiate from the closest sibling, search_agents, so an agent cannot tell from the description which of the two to pick.

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

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

No guidance on when to use this versus search_agents, get_agent, or get_leaderboard, and no mention that 'active' means some status filter. Usage is only implied by the tool name and the word 'active'.

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 that the tool is free, authenticated, nonpersistent, and creates no route/order/checkout/payment, but it does not cover rate limits, idempotency, return behavior, or other operational constraints expected for a complex planning 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?

The description is two tightly written sentences with no wasted words, and the key property (nonpersistent preview) is front-loaded. It is appropriately concise, even if the overall definition is under-specified 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?

This is a complex tool with 10 parameters, nested policy objects, only 10% schema description coverage, no annotations, and no output schema. The description states the high-level safety profile but leaves critical context missing, especially around parameters, outputs, and usage relative to siblings.

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

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

The schema has only 10% description coverage across 10 parameters, many of them nested and policy-sensitive. The description provides no parameter-level meaning at all, so it fails to compensate for the low schema coverage.

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

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

The description states a specific resource and mode: a nonpersistent route preview using the deterministic planner. It distinguishes itself from route-creating siblings by saying it creates no route, order, checkout, or payment, though it does not name the relevant sibling explicitly.

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

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

Usage is implied rather than stated: 'route preview' and 'creates no route' suggest it is for previewing before using a persistent route tool. However, the description never names alternatives such as route_work or explains exactly when to choose this tool over them.

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

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

No annotations are provided, so the description must carry the behavioral burden. It says what the tool resolves but not whether matching is exact or fuzzy, whether authentication is required, how multiple matches are handled, or what the result looks like.

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

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

The definition is a single front-loaded sentence with no filler. Every word contributes to explaining the canonicalization operation.

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 one-parameter lookup with no output schema and no annotations, the description covers the core operation but leaves return shape and matching behavior unstated. It is minimally sufficient but not complete enough to set expectations for an agent consuming results.

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

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

The sole parameter q has 0% schema description coverage, so the description must compensate. Calling it "free-form capability text" adds useful meaning beyond the bare string schema, but it does not specify format, examples, or expected length.

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, "Resolve," and a concrete transformation: free-form capability text into canonical tags. It is clear enough to distinguish this from a generic capability lookup, though it does not explicitly contrast itself with the sibling get_capabilities.

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 "free-form capability text" implies the input situation, but there is no explicit guidance on when to choose this tool over get_capabilities or browse_tasks. No exclusions or alternatives are mentioned.

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

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

With no annotations, the description carries the full behavioral burden and does a lot: it names the required auth scopes, declares "Never funds, signs or accepts output" (bounding side effects for a payments-adjacent tool), and gives idempotency guidance ("Reuse client_reference exactly after an uncertain response"). What's missing is a clear statement that this is a state-changing submission and what it returns on success.

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

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

It is compact, but front-loading is poor: "Free MCP 2025-11-25 task submission" is cryptic noise before the actual function, and several sentences are dense jargon. Most sentences do carry information (auth, modes, constraints), but the packaging makes them hard to parse rather than efficiently structured.

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 complex tool (nested `request` object, oneOf branching, no output schema, no annotations) the description covers auth, mode selection, side-effect limits, and idempotency. However, it leaves the nested `request` payload entirely unexplained, which is the largest unknown for correct invocation.

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

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

Schema description coverage is only 25% (only `request` is documented), so the description should compensate. It does add meaning to client_reference (an idempotency key to reuse) and gestures at route_id/mandate_id via "owned route with its saved mandate," but it never explains what these UUIDs are or how the two oneOf branches map to them.

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?

It states a verb-ish function ("task submission" / "route work") and mentions the two operating modes (persist an objective vs. reserve a route with a mandate), so an agent can grasp the general shape. But the language is heavy jargon ("task augmentation", "reserve an owned route") and never distinguishes it from siblings like plan_work or continue_route, leaving genuine ambiguity about its specific role.

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 real usage context: prerequisites (registered-agent key with agent:read, marketplace:write, payments:write) and the two entry modes. But it never says when to prefer this over plan_work/continue_route or when not to use it, so the routing guidance is 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?

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about result ordering/relevance, the default behavior of the two boolean filters, or the interaction of verified and work_proof. 'Search' implies a read, but that is inference rather than stated behavior.

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

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

A single front-loaded sentence with no wasted wording. It is efficient, though the terseness leaves useful information unstated rather than merely trimmed.

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

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

For a 5-parameter semantic search with no annotations and no output schema, the description should at least sketch ranking/pagination behavior and clarify how the verified/work_proof filters narrow results. It omits all of that, leaving the agent dependent on sibling inference and 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?

Schema description coverage is 100% and the schema itself carefully documents q, page, limit, verified and work_proof, including the intersection semantics of the two flags. The description adds nothing beyond the schema, 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 (Search), resource (agents) and the query mechanism (natural language capability query), which implicitly separates it from list_agents. It does not explicitly name the sibling or state the contrast, so an agent must infer the semantic-vs-listing distinction.

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

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

No when-to-use guidance and no mention of alternatives such as list_agents, get_capabilities or resolve_capabilities, all of which plausibly overlap. The agent must guess which retrieval tool to pick for a given intent.

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