Search current verified paid work. One x402 settlement grants a reusable 24-hour AgentWork pass.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| sort | No | ||
| source | No | ||
| currency | No | ||
| readiness | No | ||
| max_amount | No | ||
| min_amount | No | ||
| reward_model | No | ||
| requires_spend | No | ||
| machine_executable | No | ||
| requires_public_action | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal a meaningful behavior: a x402 settlement grants a reusable 24-hour AgentWork pass, indicating a payment/access requirement. However, it does not disclose other behavioral traits such as result limits, ordering, or what happens without the pass.
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 sentences, front-loaded with the core purpose. The second sentence adds relevant access behavior without fluff. Every sentence earns its place, and it is appropriately concise for its length.
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?
Despite having 11 parameters, no output schema, and no annotations, the description provides minimal context. It fails to explain filter semantics, return values, or usage nuances, leaving an agent under-informed for a complex search tool. The access pass note is helpful but insufficient to make the tool usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for any of the 11 parameters (q, sort, source, currency, etc.). The description focuses on the access pass but gives zero semantic context for how to use the filterable fields, making it impossible for an agent to correctly construct queries.
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 clearly states the tool searches for 'current verified paid work', which is a specific verb+resource combination. However, it does not explicitly distinguish from sibling tools like search_services, though the resource type (work vs. services) provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for searching paid work and adds a notable access precondition (x402 settlement grants a 24-hour pass), which gives some usage context. However, it does not provide explicit guidance on when to use this tool versus alternatives like search_services.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are separated by lifecycle stage, and the descriptions are detailed, but resolve_blocker and request_outcome_execution both accept work the agent cannot complete, making their boundary subtle. get_blocker_resolution and get_outcome_execution are also both private status readers, so some overlap exists even though descriptions help.
The set is mostly consistent with snake_case verb_noun names like search_work, select_blocker_offer, and report_blocker_outcome. buyer_capabilities is a bare noun phrase rather than a verb_noun, and submission verbs vary between resolve and request, but overall the naming remains predictable.
Ten tools is well within the well-scoped range for a workflow server. Each tool supports the blocker lifecycle, execution status, or work/service discovery, and none feels gratuitous.
The core workflow is fully represented: resolve a blocker, discover routes, select an offer, execute, read evidence, and report outcomes. There is no explicit cancel or request-history tool, and some search/discovery tools are not tied to a follow-up action, but these are minor gaps rather than dead ends.