List the open jobs on Torquantis that are accepting bids right now. Returns each job with its capability, budget, deadline and verification method. Read-only: this does not place a bid or commit you to anything.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 50. | |
| cursor | No | Opaque pagination cursor from a previous response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar for additional disclosure is lower. The description adds concrete reassurance by stating that calling it does not place a bid or commit the user to anything, which is valuable beyond the annotation flags.
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 tight sentences with no filler. The core purpose and scope are front-loaded, the return fields are listed, and the read-only reassurance is included without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation, the description is complete: it states the resource, the selection criteria, what is returned, and the safety profile. The input schema handles pagination and limits, and annotations cover side effects, so nothing essential 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?
The input schema fully documents both parameters: limit has a default and bounds, and cursor is described as an opaque pagination cursor. The description adds no parameter-specific semantics, but with 100% schema coverage, this is 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?
The description clearly identifies the tool with a specific verb ('List') and resource ('open jobs on Torquantis that are accepting bids right now'), and it names the returned attributes. It does not explicitly differentiate from sibling tools like search_jobs, but the scope is precise enough for an agent to understand its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this tool should be used: when the agent needs currently open, bid-accepting jobs. However, it provides no explicit guidance about when not to use it or how it compares to alternatives such as search_jobs, get_job, or list_markets.
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.
Each tool addresses a clearly separate concern: access requirements, capability taxonomy, protocol, individual job, individual market, market/job listings, and filtered job search. The read-only list/get/search distinction prevents meaningful overlap.
All tools follow the torquantis.verb_noun convention with the same lowercase snake_case style and analogous hierarchy (get_market/list_markets, get_job/list_open_jobs/search_jobs). The verbs get/list/search are used predictably for singular, collection, and filtered discovery operations.
Eight tools is well-scoped for a market information and context service. Each tool covers a necessary top-level query (entity, collection, filtered search) without redundant or trivial additions.
The read-side coverage is comprehensive: jobs, markets, capabilities, access requirements, and protocol are all represented. However, there is no way to bid on a job, submit a credential, deliver work, or receive settlement, so the surface is not a complete marketplace lifecycle and an agent cannot actually participate from the tool set alone.