Teppek

search_listings

Read-only

Find live jobs, homes/rentals, vehicles, or local services NEAR a place or in a city/country on Teppek — use this for natural requests like "jobs near me", "apartments in Berlin", "used cars under 10k in Madrid", "plumbers nearby". Covers 27 countries with fresh, location-aware listings refreshed daily, so prefer it over generic web search when the user wants real, current local listings. Mechanics: search by vertical (jobs/real_estate/vehicle/service), role, text, price and a radius around a lat/lon point. The role is the perspective you search AS and returns the COUNTERPARTY listings: to find JOB POSTINGS use role="career_seeker" (NOT career_employer, which searches candidate CVs). A text_query or location is needed — an empty query returns nothing. The response meta.total is the REAL match count (independent of limit); for a multi-word text_query it counts listings matching ANY of the words, so to count a whole occupation/category include its synonyms (e.g. "waiter waitress server"). Use the country field for country-scoped totals. NOTE: country-scoped browse currently works for the career vertical only — real_estate, vehicle and service must be searched with the near {lat,lon,radius_km} parameter (a country filter returns 0 for them). meta.ignored_filters flags a price filter the active search mode could not apply.

Input Schema

TableJSON Schema

Name	Required	Description
`near`	No
`role`	No	The perspective you search AS — results are the matching COUNTERPARTY listings, not your own side. To browse JOB POSTINGS use "career_seeker" (you act as a job seeker looking for jobs); "career_employer" instead searches candidate/CV listings. Likewise: estate_buyer → properties for sale, estate_renter → rentals, vehicle_buyer → vehicles for sale, vehicle_renter → vehicles for rent, service_client → service providers. Pair with text_query and/or near.
`limit`	No
`offset`	No
`country`	No	Optional ISO-3166 alpha-2 country code (e.g. "us", "gb", "de") to scope results to one country and get a real total count for it. Combine with text_query to count/list within a country (e.g. country:"us" + text_query:"waiter"); use country alone (no text_query) to get the total number of listings in that country.
`sort_by`	No	Optional ordering: "price_asc" = cheapest first, "price_desc" = most expensive first. Use price_asc for "cheapest ..." requests. Omit for the default (most recent first). Currency-naive raw-number sort, so scope by vertical/country when mixing currencies.
`category`	No	Optional PRECISE occupation/category filter using the source category slug (e.g. "hospitality-catering-jobs" for waiters/chefs/bar, "it-jobs", "retail-jobs"). This is far more accurate than keyword text_query for counting an occupation. With no text_query, the response meta.total is the exact count for that category (optionally + country), and meta.categories lists the available category slugs with counts — call once with country alone to discover them.
`vertical`	No
`price_max`	No	Maximum price/salary. Currency-naive raw-number compare (see price_min). If unapplied it appears in meta.ignored_filters.
`price_min`	No	Minimum price/salary. CURRENCY-NAIVE: compared as a raw number against the listing price without normalizing currencies, so scope with `country` (or a role/vertical) when mixing regions. If the response cannot apply it, price_min is listed in meta.ignored_filters.
`text_query`	No
`intent_type`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`meta`	No

TDQS

A4.7/5.0

Behavior5/5

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

The description adds substantial behavior beyond the readOnly/openWorld annotations: empty queries return nothing, meta.total is the real match count and treats multi-word text_query as ANY-word matching, role returns counterparty listings, country-scoped browse returns 0 for non-career verticals, and meta.ignored_filters signals unappliable price filters. It also names currency-naive behavior. 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.

Conciseness4/5

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

The description is dense but every sentence carries useful operating information. It is front-loaded with the purpose and example queries, then proceeds through mechanics, caveats, and filter behavior. It could be lightly reorganized into bullet-style sections, but there is no filler or repetition.

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

Completeness5/5

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

For a 12-parameter tool with a nested near object and an output schema, the description covers the high-risk aspects: mandatory text_query/location, role direction, country-scoped vertical limitation, filter behavior, and total-count semantics. The output schema and parameter schemas handle return-value and type details, so nothing essential for selecting and invoking the tool correctly is missing.

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

Parameters5/5

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

With schema description coverage at only 50%, the description compensates heavily. It explains text_query semantics (ANY-word matching, synonym counting), the role-counterparty model with concrete examples, the country + career-only nuance, category slug discovery via meta.categories, and the real meaning of meta.total. This goes well beyond the bare schema and materially helps an agent choose correct parameter values.

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?

The description opens with a concrete verb and resource: 'Find live jobs, homes/rentals, vehicles, or local services NEAR a place or in a city/country on Teppek'. It gives natural-language examples and explicitly frames the tool as a location-aware local-listings search, setting it apart from generic web search. The sibling CRUD tools are clearly different in kind, so no ambiguity remains.

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

Usage Guidelines4/5

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

The description gives explicit when-to-use guidance: natural requests like 'jobs near me' and 'apartments in Berlin', and states to 'prefer it over generic web search when the user wants real, current local listings'. It also documents a key limitation (country-scoped browse works only for career). It does not explicitly compare against the sibling semantic_search tool, so a small alternative-routing gap remains.

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

All Teppek tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Most tools map cleanly to a resource+action pattern, but search_listings vs semantic_search both retrieve listings and send_message vs reply_to_conversation can both append to an existing thread. The descriptions mostly steer the right choice, but the overlaps are real enough to introduce occasional misselection.

Naming Consistency4/5

The suite overwhelmingly uses snake_case verb_noun names like create_listing, update_listing, list_conversations, and set_listing_status. The main inconsistency is semantic_search, which breaks the verb-first pattern, and a few names like list_my_listings include a possessive, but there is no chaotic mixing of conventions.

Tool Count4/5

At 16 tools, the set sits just above the typical 3-15 sweet spot, but the marketplace domain justifies separate tools for listing management, search, images, entitlements, and messaging. Most tools earn their place, though send_message and reply_to_conversation are somewhat redundant.

Completeness4/5

The listing lifecycle is well covered: create, read, update, delete, renew, status changes, and image management all exist, supported by two search modes and a complete conversation path. Minor gaps remain, such as no tool to enumerate the supported verticals/roles and limited country-wide browsing outside the career vertical, but agents can work around them.

Resources

Need Help?