Bettan

Search listings

search_listings

Read-only

Search active listings on Bettan, newest first. All filters are optional. Returns compact results; use get_listing for the full description. When more match, the result has next: pass it as after (with the same filters) for the next page.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_listings"
  }
}

Input Schema

Name	Required	Description
`city`	No	Town name, e.g. "Zürich".
`sort`	No
`after`	No	The `next` value from an earlier result with the same filters, for the next page.
`limit`	No
`query`	No	Words to look for in the title and description, e.g. "road bike".
`yearMax`	No	Vehicles: latest model year.
`yearMin`	No	Vehicles: earliest model year.
`category`	No
`currency`	No	Currency of minPrice and maxPrice. Defaults to the one the countries share. Listings in other currencies are left out when a price filter is set.
`handover`	No
`maxPrice`	No	In `currency`.
`minPrice`	No	In `currency`.
`condition`	No
`countries`	No	ISO country codes to search in. Leave out to search all countries.
`mileageMax`	No	Vehicles: highest mileage.
`mileageUnit`	No
`vehicleType`	No	Only with category "vehicles".

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026

addedInput schema / properties / after

Added value: +{
+  "description": "The `next` value from an earlier result with the same filters, for the next page.",
+  "type": "string"
+}

First observedNov 11, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description correctly aligns with that by describing a pure read/search. It adds useful behavior beyond annotations: results are compact rather than full records, ordering defaults to newest first, and a `next` cursor appears only when more matches exist. It does not mention rate limits or result-field contents, which keeps it short of a 5.

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

Conciseness5/5

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

Three short sentences, front-loaded with purpose, then the sibling routing, then pagination. Nothing is repeated and every sentence carries information an agent needs to act.

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

Completeness4/5

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

For a 17-parameter search with no output schema, the definition covers the essentials: result shape is characterized as 'compact', the pagination field is named, and the escape hatch to get_listing is provided. It stops short of describing what fields a compact result contains or how the `sort` parameter interacts with the stated 'newest first' default.

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

Parameters4/5

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

Schema coverage is 65% across 17 parameters, so the schema carries most of the weight, but the description adds the meaningful cross-parameter semantics: all filters are optional and the pagination cursor must be reused with the identical filter set. It adds no per-filter meaning (city, category, vehicleType, price/currency interaction) beyond what the schema already documents.

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

Purpose5/5

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

States a specific verb and resource ('Search active listings on Bettan'), plus the default ordering ('newest first') and the scope restriction to active listings. It also distinguishes itself from the sibling get_listing by calling its own results 'compact' and pointing at get_listing for full descriptions.

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

Usage Guidelines5/5

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

Gives explicit routing: use this tool for compact search results, use get_listing when the full description is needed. It also states that all filters are optional and spells out the exact pagination procedure (pass the returned `next` as `after` with the same filters), so an agent never has to infer continuation behavior.

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

All Bettan tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?