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. 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. Dates show when Glama detected each change.

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 declare readOnlyHint and openWorldHint. The description adds substantial context beyond them: daily refresh cadence, counterparty role semantics (career_seeker vs career_employer), the career-only country-scoping caveat, meta.total being the real match count with ANY-word matching, and meta.ignored_filters for unapplied price filters. 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 long (~180 words) but dense with non-obvious gotchas and front-loads the main use cases before mechanics. It could be better organized — behavioral notes like the country-scoping limitation and ignored_filters behavior are tucked into mid-flow sentences — but no sentence is filler given the tool's complexity.

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 nested objects, role semantics, and per-vertical search-mode constraints, the description is near-complete: it covers when to use it, the required input constraint, role mapping, country/vertical caveats, meta.total semantics, and result-count interpretation. An output schema exists so return-value documentation is unnecessary; the only real gap is intent_type, which is optional and niche.

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?

With schema description coverage at 50%, the description compensates well: it explains role counterparty behavior, the career-only country restriction, the need for a text_query or location, ANY-word matching for text_query, and ignored_filters behavior for price filters. However, intent_type (supply/demand) is never mentioned anywhere, and the `near` object's meaning is only implied as "radius around a lat/lon point", so not every parameter's semantics is fully established.

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 specific verb and resource: "Find live jobs, homes/rentals, vehicles, or local services NEAR a place or in a city/country on Teppek." It names the four verticals, the location-based scope, and concrete example queries. It also explicitly differentiates itself from semantic_search and generic web search, so an agent can distinguish it from its 15 siblings without inspecting schemas.

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?

Provides explicit when-to-use guidance: natural requests like "jobs near me" and "apartments in Berlin", preference over generic web search for current local listings, and a named alternative with its trigger condition ("For MEANING-based or fuzzy natural-language intent... use semantic_search instead"). It also states the precondition that a text_query or location is needed, which prevents empty-query calls.

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?