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. For MEANING-based or fuzzy natural-language intent (not exact keywords or filters), use semantic_search instead. 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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJul 29, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "data": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "currency": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "price": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "status": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "title": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "url": {
+            "type": "string"
+          },
+          "vertical": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "meta": {
+      "additionalProperties": {},
+      "properties": {},
+      "type": "object"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

First observedJul 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark readOnlyHint=true, but the description adds substantial behavioral depth: the counterparty role semantics (career_seeker returns job postings, not CVs), the requirement for a text_query or location (empty query returns nothing), the meta.total semantics including multi-word ANY matching, and the meta.ignored_filters flag. These go well beyond the annotation and directly inform correct invocation.

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 long but efficient; every sentence earns its place. It front-loads purpose and usage, then mechanics and caveats. It is structured with clear sections and examples. While not terse, it avoids redundancy and packs essential information, earning a high score rather than a top score for brevity.

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 tool with 12 parameters, a nested near object, and an output schema, the description is remarkably complete. It covers the core search mechanics, role semantics, result counting behavior, country limitations, and ignored filters. The output schema presumably handles return details, so nothing critical is missing for correct invocation.

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 description coverage is only 50%, so the description carries a heavier load. It explains the role parameter in detail, the need for near or text_query, and the country limitation. It does not describe every parameter (offset, limit, intent_type) but the most complex ones are covered. The description adds significant meaning beyond the schema, though it could briefly mention sort_by and intent_type.

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 precise verb-resource pairing: 'Find live jobs, homes/rentals, vehicles, or local services NEAR a place or in a city/country on Teppek'. It immediately scopes the tool and differentiates it from the sibling by naming semantic_search for 'MEANING-based or fuzzy natural-language intent'. This gives an agent clear, non-overlapping purpose.

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?

Explicitly states when to use this tool (natural location/price requests) and when not (semantic_search for fuzzy intent). It provides concrete examples ('jobs near me', 'apartments in Berlin') and a critical exclusion: country-scoped browse works only for the career vertical, with real_estate/vehicle/service requiring the near parameter. No inference is left to the agent.

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

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?