Map-first global classifieds marketplace — search and post listings across jobs, real estate, vehicles, and services, on behalf of a signed-in user.
Scored across 16 tools
Each tool has a clearly distinct role: listing CRUD, lifecycle actions, image handling, entitlements, search vs semantic search, and messaging first-contact vs reply are all explicitly separated. The descriptions actively disambiguate overlapping-sounding pairs like search_listings/semantic_search and send_message/reply_to_conversation.
The set is consistently snake_case and mostly follows a verb_noun pattern (create_listing, update_listing, get_conversation, list_my_listings). Minor deviations like semantic_search and request_image_upload are readable but not strictly verb-first.
16 tools is reasonable for a marketplace API covering listings, search, messaging, media, and entitlements. It is slightly heavy but each tool maps to a distinct operation rather than redundant surface area.
The surface covers the full listing lifecycle (create, read, update, delete, status, renew, images), public and semantic search, entitlement checks, and both first-contact and threaded messaging. No obvious core workflow dead ends remain.
Publish a listing on behalf of the user across any of the 4 verticals and 12 roles. location must be coordinates ({ lat, lon }) — a free-text address is not accepted, so geocode it first. Publishing consumes credits and requires a free listing slot; get_entitlements reports the current balance and remaining slots. A reached limit makes this return an ACTIVE_LISTING_LIMIT_REACHED error carrying a pay_url. Consumes credits and is held for AI moderation (status starts "pending"); credits are refunded if rejected, EXCEPT for prohibited or spam content, which forfeits the credit. To attach photos, first call request_image_upload for each image and pass the returned keys in images — every image is AI-moderated with the text before going live. Requires the user to be connected to Teppek: an anonymous call returns an AUTH_REQUIRED error with an authorize_url — surface "Connect with Teppek" to the user, then retry.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | The listing role — this alone fixes supply vs demand (do not send intent_type). vehicle_letter = you OWN the vehicle and are renting it OUT (lessor); for a user who WANTS to rent a vehicle use vehicle_renter. Likewise estate_landlord (renting out) vs estate_renter (wants to rent), estate_seller vs estate_buyer, career_employer (posting a job) vs career_seeker (a CV), service_pro (offering) vs service_client (wants a service). | |
| price | Yes | Asking price as a plain number in `currency`, with no separators. For a job, use the salary figure and put the range in details.salary_min and details.salary_max. Example: 950. | |
| title | Yes | Short headline of the listing, 3-200 characters. Example: "Two-bedroom flat near the river". | |
| images | No | Up to 6 image keys returned by request_image_upload, uploaded before this call. Example: ["7c9e6679-7425-40de-944b-e07fc1f90ae7"]. | |
| details | No | Vertical-specific attributes. Only these exact keys for the listing's vertical are accepted; any other key is rejected with an error. career: organization_name, employment_type, salary_min, salary_max, years_experience. real_estate: property_room_count, m2_gross, m2_net, building_age, floor_number, heating_type, deposit, dues, is_furnished, is_student_friendly, is_credit_eligible, tapu_status. vehicle: brand, model, vehicle_model_year, vehicle_mileage_km, fuel_type, gear_type, color, damage_status, daily_price, deposit. service: service_category. employment_type is one of full_time, part_time, contract, freelance, internship. is_furnished, is_student_friendly and is_credit_eligible are booleans. real_estate also accepts transaction_type (sale, rent or hire). Example: { "brand": "Toyota", "model": "Corolla", "vehicle_model_year": 2021, "vehicle_mileage_km": 40000, "fuel_type": "hybrid", "gear_type": "manual" }. | |
| currency | Yes | ISO-4217 currency code matching the listing country (e.g. USD, EUR, GBP, TRY). Required — there is no default, to avoid silently mislabeling non-Turkish listings. | |
| location | Yes | Listing coordinates as { lat, lon }. A free-text address is NOT accepted — resolve it to coordinates before calling. Example: { "lat": 48.85, "lon": 2.35 }. | |
| vertical | Yes | Listing category, which must match the role: career (jobs and CVs), real_estate, vehicle or service. Example: "vehicle". | |
| description | No | Full listing text, up to 5000 characters. Facts that fit a `details` key belong in details as well. Example: "Bright flat on the third floor, five minutes from the metro." |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior beyond the annotations: credit consumption, pending moderation status, refund policy with the prohibited/spam exception, image moderation, and two named error contracts (ACTIVE_LISTING_LIMIT_REACHED with pay_url, AUTH_REQUIRED with authorize_url). This is exactly the operational context the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) cannot carry.
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?
Front-loaded with purpose, then preconditions, then error paths — a sensible sequence. A few sentences duplicate schema descriptions verbatim (the location/coordinates warning appears in both), which is slight redundancy but defensible for a high-stakes constraint.
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?
Covers a complex 9-parameter, nested-object, mutation tool end to end: prerequisites, cost model, moderation lifecycle, error branches, and retry path. With an output schema present, no return-value explanation is required, and the soft-error contracts are still spelled out for the agent.
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?
Schema coverage is already 100%, so the baseline is 3; the description earns above that by adding workflow meaning — location must be geocoded coordinates, and `images` must hold keys returned by request_image_upload in a specific order. It leaves details.* key semantics entirely to the schema, which is reasonable given the schema documents them thoroughly.
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?
States a specific verb and resource ("Publish a listing") plus the scope ("on behalf of the user across any of the 4 verticals and 12 roles"), which maps directly to the vertical/role enums. Read against siblings like update_listing or renew_listing, the create semantics are unambiguous.
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?
Gives concrete preconditions and ordering rules: check get_entitlements before publishing, call request_image_upload per image, retry after surfacing "Connect with Teppek". It does not explicitly route an agent away from update_listing/renew_listing when the listing already exists, so it stops short of naming alternatives as exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete (soft-delete) one of the USER'S OWN listings by listing_id. Only the owner can delete. No credit is refunded — the listing was already published.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: "adzuna-us-5947308680". |
| Name | Required | Description |
|---|---|---|
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds genuinely new context beyond annotations: that deletion is a soft-delete and that no credit is refunded because the listing was already published — both material to a mutation decision.
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?
Three tight sentences, front-loaded with the action and ownership constraint, followed by the cost implication. Zero filler.
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?
An output schema exists and annotations cover safety, so the description doesn't need to explain returns. It covers ownership, soft-delete semantics, and credit behavior; only the downstream effect on related conversations/messages is unstated, a minor gap.
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?
Schema description coverage is 100%, and the listing_id description even explains where to source the value with an example. The description adds only the phrase 'by listing_id', so baseline 3 is appropriate.
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?
States a specific verb (soft-delete), resource (listing), and scope (USER'S OWN listings, by listing_id). This distinguishes it clearly from create_listing/update_listing/renew_listing siblings without needing to open any schema.
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?
Explicitly states the precondition that only the owner can delete and that no credit is refunded, which tells the agent when this call is valid and what it costs. It stops short of naming alternatives (e.g. set_listing_status for deactivation vs. true removal), leaving that routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one of the user's OWN message conversations by thread_id, including its messages (marks incoming messages read). Only threads the authenticated user participates in are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| thread_id | Yes | Conversation id (a UUID), taken from list_conversations. Example: "3f6c2a1e-8b4d-4c7a-9e21-5d0f7a6b1c34". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the otherwise puzzling readOnlyHint=false by disclosing the side effect: incoming messages are marked read. It also states the authorization boundary (only threads the user participates in are returned). It does not describe what happens when the thread_id is invalid or the user is not a participant, but the important behavior is covered.
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?
Two compact sentences; the core action and scope come first, followed by the side-effect caveat and access restriction. No filler.
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?
An output schema exists so return values need no explanation, the single parameter is fully documented, and the description covers the two things structured fields cannot: the read-marking side effect and the participation filter. Nothing material is missing for a one-param read tool.
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?
Schema coverage is 100% and the thread_id parameter already documents its UUID format, example, and provenance from list_conversations. The description only restates that lookup is by thread_id, adding no format or constraint detail beyond the schema — baseline 3.
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?
States a specific verb (Read) and resource (one of the user's OWN message conversations) plus scope (by thread_id, including its messages). It implicitly separates itself from list_conversations by fetching a single thread, but never names that sibling explicitly.
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?
Usage context is implied by 'by thread_id' and the schema's reference to list_conversations as the id source, so an agent can infer the list-then-read flow. However, there is no explicit when-to-use/when-not statement or named alternative (e.g., use list_conversations to enumerate, reply_to_conversation to answer).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the user's publishing entitlements BEFORE attempting to publish: membership tier, max vs current active listings, remaining slots, wallet credit balance, the per-listing credit cost, and can_create_listing. When the limit is reached the response indicates whether the user can pay from wallet credit or should open checkout (pay_url).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description only needs to add context — which it does by disclosing what the response contains and how to interpret the limit-reached case. It stops short of describing the pay_url handoff mechanics or whether credit balances expire, but the important behavioral signal (check before writing) is present.
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?
Front-loads the actionable instruction and follows with the field list and the limit-reached branch. Slightly dense in the middle enumerating six fields, but every item aids interpretation and nothing is redundant filler.
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 zero-parameter read with an output schema already present, this is everything an agent needs: the precondition (before publishing), the payload contents, and the decision to make on a limit-reached result. No gaps that would cause a mis-call.
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?
Zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description wisely spends its words on return semantics instead of inventing parameter guidance.
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?
Names a specific resource (publishing entitlements) and enumerates exactly what it returns: membership tier, max vs current active listings, remaining slots, wallet credit, per-listing credit cost, and can_create_listing. That enumeration clearly separates it from the sibling listing CRUD tools, which mutate listings rather than report limits.
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?
States the timing explicitly — 'BEFORE attempting to publish' — which is the exact condition an agent needs to gate a create_listing call. It also names the downstream branch: pay from wallet credit or open checkout via pay_url when the limit is reached.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full detail of ONE Teppek listing by id — title, description, price/salary, location and the Teppek contact route. Use after search_listings to show, summarize or compare a specific job, home, vehicle or service the user picked.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: "adzuna-us-5947308680". |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| price | No | |
| title | No | |
| status | No | |
| currency | No | |
| vertical | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds what is actually returned, including the Teppek contact route, which is real value beyond the annotations. It does not say what happens for an unknown or stale id, which is the main remaining behavioral gap.
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?
Two sentences, zero waste: the identity/scope sentence comes first and the routing guidance second. Every clause carries information an agent needs.
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?
With a full output schema present, return values need not be spelled out, and one parameter is fully documented in the schema. What is thin is failure behavior — whether a missing or expired id errors or returns empty — for an open-world, id-keyed fetch.
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?
Schema coverage is 100% and the schema itself already explains that listing_id comes from the `id` field of search_listings/semantic_search/list_my_listings, with an example. The description only restates 'by id', so the baseline 3 is appropriate rather than a higher score.
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?
States a specific verb and resource ('Fetch the full detail of ONE Teppek listing by id') plus the exact payload (title, description, price/salary, location, contact route). The capitalized 'ONE' and the id-keyed scope separate it cleanly from search_listings and list_my_listings.
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?
Explicitly says to use it after search_listings when the user has picked a specific job, home, vehicle or service, and names the show/summarize/compare intents. It lacks an explicit 'do not use for browsing/listing' exclusion, but the condition is clear enough to select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's OWN listing-message conversations (threads they started, or received as a listing owner), newest first. Resolved from the authenticated agent key — only ever this user's threads. Use get_conversation to read a thread's messages.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return per page, 1-50. Default 20. Example: 10. | |
| offset | No | How many results to skip, for paging. Default 0. Example: 20 returns the second page when limit is 20. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations (readOnlyHint/openWorldHint already cover the safety profile) by disclosing sort order ('newest first') and the auth-derived scoping ('resolved from the authenticated agent key — only ever this user's threads'). It doesn't mention pagination behavior, but the schema's limit/offset already covers that.
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?
Three sentences, all load-bearing: scope, ordering/identity constraint, and next-step pointer. The key constraint (own threads only) is front-loaded.
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?
With an output schema present and both params fully documented, the description only needs to establish scope, ordering, and the sibling relationship — all of which it does. A note on pagination expectations would round it out, but 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?
Schema description coverage is 100%, so both limit and offset are fully documented with defaults, bounds, and examples. The description adds no parameter meaning beyond that, so baseline 3 applies.
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?
States a specific verb and resource ('List ... listing-message conversations') with precise scope: threads the user started or received as listing owner. The parenthetical definition distinguishes list_conversations from sibling listings/message tools at a glance.
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?
Explicitly routes to get_conversation for reading a thread's messages, which is the natural next step and removes ambiguity about what this tool returns. No explicit when-not conditions (e.g., vs. semantic_search or search_listings), but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's OWN listings (any status), newest first. Resolved from the authenticated agent key — only ever returns this user's listings. Use status='pending' to see what is awaiting moderation, status='rejected' for declined ones.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return per page, 1-50. Default 20. Example: 10. | |
| offset | No | How many results to skip, for paging. Default 0. Example: 20 returns the second page when limit is 20. | |
| status | No | Filter YOUR listings by moderation/lifecycle status. Use "pending" to see what is awaiting AI moderation, "rejected" for declined ones, "all" (default) for everything. | all |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| listings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavioral facts beyond that — results are scoped to the authenticated agent key, ownership is enforced server-side, and ordering is newest-first. It does not discuss pagination limits or what the response envelope looks like, but an output schema exists to cover returns.
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?
Three short sentences, zero filler, and the most consequential constraint (own listings only, agent-key resolved) is front-loaded before the filter hints. Every sentence carries distinct information.
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?
With only three optional, fully documented parameters, an output schema for return values, and annotations covering the safety profile, the description supplies exactly the missing piece: ownership scoping and the authenticated-key resolution model. Nothing an agent needs to invoke this correctly is absent.
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?
Schema description coverage is 100%, so the schema already documents limit, offset, and every enum value of status in detail. The description's pending/rejected hints restate what the schema's status description already says, adding no new syntax, defaults, or edge-case meaning. Baseline 3 is appropriate.
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?
States a specific verb and resource (list listings) plus the crucial scope qualifier: only the caller's OWN listings, keyed to the authenticated agent. The 'any status, newest first' clause and the emphasis on ownership distinguish it cleanly from sibling tools like search_listings and get_listing without needing to open either schema.
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?
Gives concrete selection guidance for the status filter ('use pending to see what is awaiting moderation, rejected for declined ones') and establishes the ownership precondition that tells the agent when this tool applies at all. It stops short of naming an explicit alternative for cross-user lookup (e.g., search_listings), so no exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renew one of the USER'S OWN listings — extend its expiry another 30 days (native listings lapse ~30 days after posting). Free — no credit charge. Renewing an expired listing returns it to active; a pending, rejected, sold, or draft listing cannot be renewed.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: "adzuna-us-5947308680". |
| Name | Required | Description |
|---|---|---|
| listing | Yes | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: it is free with no credit charge, it mutates listing state (expired → active), and it enumerates the statuses that block renewal. These details are the ones an agent must know before calling a non-idempotent, non-read-only mutation.
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?
Three short sentences, front-loaded with the action and scope, then cost, then state rules. No filler and nothing repeated from the annotations.
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?
An output schema exists so return values need no explanation, and cost plus state eligibility are covered. The one ambiguity is whether the 30 days accrue from now or from the existing expiry for an active listing.
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?
Schema coverage is 100% and listing_id is already documented with a source and example, so the schema carries most weight. The description still adds the critical constraint that the id must belong to the caller's own listings, which the schema does not convey.
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?
States a specific verb and resource (renew a listing) plus the exact effect (extend expiry by 30 days) and the ownership scope (USER'S OWN). An agent can distinguish this from update_listing or set_listing_status without opening the schema.
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?
Gives explicit when-not conditions: pending, rejected, sold, or draft listings cannot be renewed, while expired ones return to active. It lacks a named alternative (e.g., use set_listing_status to reactivate a sold item), so the routing guidance is clear but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Continue an EXISTING message thread by thread_id — the message goes to the other participant. Use this to follow up in a conversation that already exists, whether the user is the listing owner answering an inquiry or the inquirer following up. For the FIRST message to a listing found in search (you have a listing_id but no thread yet), use send_message instead. Contact routes through Teppek; raw personal details are never exposed. Find thread_id via list_conversations / get_conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The reply to post into the conversation, up to 2000 characters. Contact routes through Teppek; raw personal details are never exposed. Example: "That time works for me." | |
| thread_id | Yes | Conversation id (a UUID), taken from list_conversations. Example: "3f6c2a1e-8b4d-4c7a-9e21-5d0f7a6b1c34". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true and idempotentHint=false, so the write/non-idempotent profile is known. The description adds genuinely new context: the message is delivered to the counterparty and contact is proxied through Teppek with no raw personal details exposed. It does not address failure modes (invalid, closed, or someone else's thread_id) or any rate limits, which is the main gap.
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?
Front-loaded with the action and scope, then the alternative, then the trust note, then the id lookup — a sensible ordering with no wasted preamble. The 'Contact routes through Teppek; raw personal details are never exposed' sentence partly duplicates the body parameter description, a minor redundancy.
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?
Output schema exists so return values need no explanation, and annotations cover the safety profile; the description supplies the decision rule against the nearest sibling and how to obtain the required thread_id. Only error/closed-thread behavior is left unstated, which is not strictly necessary to invoke it correctly.
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?
Schema description coverage is 100% and both parameters are documented with examples and length bounds, so the baseline is 3. The description reinforces the thread_id provenance (list_conversations / get_conversation) but adds no format or constraint detail the schema does not already carry.
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?
States a specific verb and resource ('Continue an EXISTING message thread by thread_id') plus the observable effect ('the message goes to the other participant'). It is immediately distinguishable from sibling send_message and from read-only siblings like get_conversation.
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?
Explicitly names both roles that should use it (listing owner answering, inquirer following up) and gives a concrete exclusion: for the first message to a listing found in search with a listing_id but no thread, use send_message instead. It also routes the agent to list_conversations / get_conversation to obtain thread_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a short-lived upload grant to attach a photo to a listing you're about to publish (any vertical/role). Returns { key, upload_url, upload_token, headers_required }: POST the raw image bytes to upload_url with those headers, then pass the returned key in create_listing's images array. Images are AI-moderated (content safety + consistency with the listing text) before the listing goes live.
| Name | Required | Description | Default |
|---|---|---|---|
| file_size | Yes | Exact file size in bytes, at most 10485760 (10 MB). Example: 2097152 for a 2 MB file. | |
| content_type | Yes | MIME type of the image file. Example: "image/png". |
| Name | Required | Description |
|---|---|---|
| key | No | |
| upload_url | No | |
| upload_token | No | |
| headers_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say this is a non-read-only, non-destructive, non-idempotent, closed-world call; the description adds the crucial traits: the grant is short-lived, the exact return fields, the required POST-with-headers mechanics, and that images pass AI moderation (content safety + text consistency) before going live. That is behavior an agent could not infer from annotations.
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?
Three tight sentences: what you get, how to use it, and the downstream consequence. The call-to-action chain (POST bytes → take key → pass to create_listing) is front-loaded with zero filler.
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?
Covers the full lifecycle an agent needs: request grant, upload mechanics, key handoff, and moderation gate. Even though an output schema exists, the return fields are named inline so the agent need not cross-reference before acting.
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?
With 100% schema description coverage including an enum and an explicit 10 MB maximum, the schema carries the parameter burden. The description adds no meaning about file_size or content_type and only describes the output-side contract, so baseline 3 applies.
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?
States a specific verb and resource ('get a short-lived upload grant to attach a photo') with scope ('any vertical/role') and explicitly separates it from the listing-creation sibling by naming create_listing's images array. An agent can place this tool in the workflow without opening a schema.
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?
Clear about the context of use: a listing you're about to publish, with the resulting key fed into create_listing. It does not address the sibling update_listing_images, which is presumably the path for editing images on an existing listing, so the when-not is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 (career/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). Always send role with text_query: without it the call fails with an error, and vertical alone is not enough. country, category and near work without role; a call with none of text_query, country, category or near returns nothing. Real estate inventory is currently very limited, so an empty real_estate result does not mean the search failed. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | Radius search around a point, and the way to search real_estate, vehicle and service by place. Works without role or text_query. Example: { "lat": 48.85, "lon": 2.35, "radius_km": 25 }. | |
| 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. REQUIRED whenever text_query is sent; also works with near. | |
| limit | No | Maximum results to return per page, 1-50. Default 20. Example: 10. | |
| offset | No | How many results to skip, for paging. Default 0. Example: 20 returns the second page when limit is 20. | |
| 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. Career vertical only. Combine with role + text_query to count/list within a country (e.g. role:"career_seeker", country:"de", text_query:"kellner"); 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 | Listing category: career (jobs and CVs), real_estate, vehicle or service. It does not replace `role`: a text_query still needs role. Example: "vehicle". | |
| price_max | No | Maximum price/salary. Currency-naive raw-number compare (see price_min). If unapplied it appears in meta.ignored_filters. Example: 2000. | |
| 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. Example: 500. | |
| text_query | No | Keywords matched against listing text. Always send `role` with it: without role the search fails or returns nothing, and vertical alone is not enough. Several words match listings containing ANY of them. Example: "toyota". | |
| intent_type | No | Which side of the market to return: supply = things on offer (job postings, homes, vehicles, services), demand = people looking for them. Usually unnecessary when role is set. Example: "supply". |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| meta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, but the description adds substantial non-annotation behavior: text_query without role fails, vertical alone is insufficient, a call with no text_query/country/category/near returns nothing, country browse only works for career vertical, and meta.ignored_filters signals unapplied filters. These are real failure modes disclosed up front.
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?
Front-loaded with purpose and examples, then mechanics, then edge cases — a logical flow. It is dense and long, with role guidance effectively repeated from the schema, but nearly every sentence carries operational value rather than filler.
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?
A 12-parameter, nested-object tool with already rich schema and an output schema, and the description still covers the failure modes, mode-specific limitations, and meta-field interpretations an agent needs. Nothing material for correct invocation 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?
Schema coverage is 100%, so individual parameters are already well-documented. The description still adds cross-parameter semantics not fully captured per-field: role must accompany text_query or the call fails, vertical does not replace role, and country-scoped search is career-only — practical relationships between params.
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?
States a specific verb and resource ('Find live jobs, homes/rentals, vehicles, or local services') with scope qualifiers (NEAR a place, city/country, 27 countries). Immediately distinguishes itself from the semantic_search sibling and gives concrete example queries an agent can pattern-match against.
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?
Explicitly says when to use this tool, when to use semantic_search instead ('MEANING-based or fuzzy natural-language intent'), and which parameter combinations are required vs optional. Also gives the crucial caveat that empty real_estate results mean limited inventory, not failure — actionable guidance an agent would otherwise misread.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic (meaning-based) search over Teppek's live listings, backed by a multilingual embedding index. Use it when the user describes what they want in natural language rather than exact keywords — e.g. "outdoor jobs that don't need a degree", "affordable family cars that are good in snow", "a cosy studio close to the university". Returns the closest-matching ACTIVE listings ranked by semantic similarity (each item carries a score). Complements search_listings: prefer search_listings for precise keyword/role/country/category/price filtering and exact counts; prefer semantic_search when meaning, synonyms, or fuzzy intent matter more than literal terms. Optional vertical narrows to career/real_estate/vehicle/service.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return, 1-20. Default 20. Example: 10. | |
| query | Yes | Natural-language description of what the user wants (e.g. "quiet night-shift jobs that do not need a degree", "cosy family flat near a park"). Matched by MEANING against the listing text, not exact keywords. | |
| vertical | No | Optional vertical filter (career | real_estate | vehicle | service) applied server-side to the active listings before they are returned. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real value beyond that by disclosing that only ACTIVE listings are returned, that results are ranked by semantic similarity, and that each item carries a `score`. It does not cover error/latency behavior or what happens on zero matches, so it stops 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and mechanism are front-loaded, and the sibling-comparison sentence earns its length. The three illustrative query examples are somewhat redundant with the examples already in the `query` schema field, so a little trimming is possible.
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?
With an output schema present the description needn't explain return values, and it still flags the `score` field and the ACTIVE-only filter. Purpose, routing, mechanism, and the one meaningful filter (vertical) are all covered for a simple 3-parameter read tool.
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?
Schema description coverage is 100%, so all three parameters are already documented in the schema, including the vertical enum. The description restates the vertical options and reinforces that `query` is matched by meaning, but adds no syntax or format detail beyond the schema — baseline 3 is appropriate.
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?
States a specific verb and resource ('semantic search over Teppek's live listings') plus the mechanism (multilingual embedding index). It explicitly contrasts itself with the sibling search_listings, so an agent can pick the right tool without opening either schema.
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?
Gives concrete when-to-use examples in natural language and an explicit routing rule: prefer search_listings for precise keyword/role/country/category/price filtering and exact counts, prefer semantic_search when meaning, synonyms, or fuzzy intent matter more than literal terms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START contact with the owner of a Teppek LISTING on the user's behalf (identified by the listing) — the primary FIRST-CONTACT path (there is no price-offer/accept/reject flow). Opens a private thread with the owner; contact routes through Teppek and never exposes raw personal details. To continue a thread that already EXISTS (you have a thread_id from list_conversations), use reply_to_conversation instead. External-feed listings (e.g. imported jobs) have no Teppek owner, so this returns a redirect to the external application URL instead of creating a thread. Requires the user to be connected to Teppek: an anonymous call returns an AUTH_REQUIRED error with an authorize_url — surface 'Connect with Teppek' to the user, then retry.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The message to send to the listing owner, up to 2000 characters. Contact routes through Teppek; raw personal details are never exposed. Example: "Hello, can I view the flat this week?" | |
| listing_id | Yes | Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: "adzuna-us-5947308680". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations (which only say non-readonly, open-world, non-idempotent): discloses that contact routes through Teppek without exposing personal details, that external-feed listings return a redirect URL instead of a thread, and that anonymous calls return AUTH_REQUIRED with an authorize_url to surface. This is exactly the behavioral context an agent needs.
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?
Front-loads the core action and the sibling alternative before edge cases, and every clause carries information. It is somewhat dense as a single paragraph with multiple parentheticals, which slightly hurts scannability.
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?
An output schema exists so return values need no explanation, and the description still covers the tricky cases (redirect for external listings, AUTH_REQUIRED flow). Nothing an agent needs to invoke it correctly 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?
Schema description coverage is 100%, so listing_id and body are already documented in the schema, including length limits and examples. The description adds only the provenance hint for listing_id indirectly; baseline 3 applies when the schema does the heavy lifting.
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?
States a specific verb (START contact), a specific resource (owner of a Teppek LISTING), and the scope (primary first-contact path, no offer/accept flow). It is immediately distinguishable from reply_to_conversation and other siblings.
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?
Explicitly names the alternative (reply_to_conversation with a thread_id from list_conversations) and the condition that selects it, plus clarifies there is no price-offer flow. When-to-use and when-not-to-use are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the lifecycle status of one of the USER'S OWN listings: mark it sold, hide it (take it offline), or re-activate a hidden one. Free — no credit charge. Cannot set moderation states (pending/rejected); re-activating only works on a listing that was previously approved and is currently hidden.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | sold = mark the listing sold/closed; hidden = temporarily take a live listing offline; active = re-show a listing that is currently hidden (only works if it was previously approved). Cannot set moderation states. | |
| listing_id | Yes | Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: "adzuna-us-5947308680". |
| Name | Required | Description |
|---|---|---|
| listing | Yes | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, idempotent and non-destructive; the description adds genuinely new context: ownership requirement, zero credit cost, and the rule that re-activation only works on a previously approved hidden listing. It stops short of saying what happens on an invalid id or a listing that isn't hidden.
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?
Three tight sentences, front-loaded with the action and its scope, then cost, then constraints. Nothing is wasted or repeated except a minor overlap between the 'hidden' wording and the re-activation caveat.
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?
An output schema exists so return values need no explanation, and the description covers ownership, cost, allowed transitions and preconditions. Only failure-mode behavior (unknown listing id, listing already in target state) is left unstated.
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?
Schema coverage is 100% and the status enum already documents each value, so the description's restatement of the sold/hidden/active semantics adds little beyond the schema. Baseline 3 applies when the schema carries the parameter burden.
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?
Specific verb+resource ('Change the lifecycle status of one of the USER'S OWN listings') with the three allowed state transitions enumerated. The scope qualifier (own listings) and the explicit exclusion of moderation states separate it cleanly from update_listing and delete_listing.
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?
Gives concrete when-to-use conditions (mark sold, hide/offline, re-activate) plus when-not (cannot set pending/rejected) and a precondition for the active transition. It does not name a sibling alternative by name (e.g. update_listing for content edits), so it falls just short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit fields (title, description, price, currency, location, details) on one of the USER'S OWN listings, identified by listing_id. Only the owner can edit; vertical/intent_type/role are fixed (publish a new listing to change those). Editing is free (no credit charge). Changing the title, description, location or details re-triggers AI moderation: the listing returns to 'pending' and is offline until cleared. Price/currency-only edits stay live. On a listing published by an assistant, price, currency and the money details are locked and rejected with price_locked.
| Name | Required | Description | Default |
|---|---|---|---|
| price | No | New asking price as a plain number. Rejected with price_locked on a listing published by an assistant. To change a salary range use details.salary_min and details.salary_max. Example: 950. | |
| title | No | New headline, 3-200 characters. Returns the listing to "pending". Example: "Two-bedroom flat near the river". | |
| details | No | Vertical-specific attributes to change. Only these exact keys for the listing's vertical are accepted; any other key is rejected with an error. career: organization_name, employment_type, salary_min, salary_max, years_experience. real_estate: property_room_count, m2_gross, m2_net, building_age, floor_number, heating_type, deposit, dues, is_furnished, is_student_friendly, is_credit_eligible, tapu_status. vehicle: brand, model, vehicle_model_year, vehicle_mileage_km, fuel_type, gear_type, color, damage_status, daily_price, deposit. service: service_category. employment_type is one of full_time, part_time, contract, freelance, internship. is_furnished, is_student_friendly and is_credit_eligible are booleans. Any details edit returns the listing to "pending", so it goes offline until AI moderation clears it. On a listing published by an assistant, salary_min, salary_max, deposit and daily_price are locked and rejected with price_locked. Example: { "m2_gross": 90 }. | |
| currency | No | New ISO-4217 currency code. Rejected with price_locked on a listing published by an assistant. Example: "EUR". | |
| location | No | New listing coordinates { lat, lon }. Moving a listing re-triggers AI moderation — it returns to "pending" until cleared. Example: { "lat": 48.85, "lon": 2.35 }. | |
| listing_id | Yes | Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: "adzuna-us-5947308680". | |
| description | No | New full listing text, up to 5000 characters. Returns the listing to "pending". Example: "Bright flat on the third floor, five minutes from the metro." |
| Name | Required | Description |
|---|---|---|
| listing | Yes | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the moderation lifecycle: title/description/location/details edits return the listing to 'pending' and take it offline until AI moderation clears it, while price/currency-only edits stay live. It adds ownership constraints, the no-credit-charge fact, and the price_locked rejection rule for assistant-published listings — exactly the behavioral context a mutation tool needs.
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?
Front-loaded with purpose, then consequences, then lock rules — a logical order with no filler. It runs several sentences, but nearly every one carries a distinct operational fact (ownership, free, moderation, price_locked).
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 7-parameter nested mutation tool with a rich schema and output schema, the description covers everything the schema cannot: ownership requirement, moderation/offline consequence, cost, and the assistant-published lock behavior. Nothing an agent needs before calling 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?
Schema coverage is 100%, so the baseline is 3; the description earns extra by stating which parameter groups trigger re-moderation versus which stay live, and by explaining the price_locked rejection semantics per parameter. It doesn't duplicate the key lists already in the details schema, which is appropriate.
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 opening sentence names a specific verb (edit), an explicit resource (one of the USER'S OWN listings), the editable field set, and the identifier (listing_id). It also states the boundary condition — vertical/intent_type/role are fixed and require a new listing — which separates it from create_listing.
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?
Clear context: only the owner can edit, and changes to vertical/intent_type/role must go through publishing a new listing. It does not route away from close siblings like update_listing_images or set_listing_status, so an agent must infer that images and status transitions belong elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add and/or remove photos on one of the USER'S OWN existing listings (max 6 total). First call request_image_upload for each new image and upload the bytes, then pass the returned keys in add. Adding any image re-triggers AI moderation — the listing returns to 'pending' until the new images are cleared; removing images does not. Free (no credit).
| Name | Required | Description | Default |
|---|---|---|---|
| add | No | Image keys from request_image_upload to attach (upload the bytes first). Each newly-added image is AI-moderated with the listing, so the listing returns to "pending" until cleared. Max 6 images total on a listing. Example: ["7c9e6679-7425-40de-944b-e07fc1f90ae7"]. | |
| remove | No | Image keys currently on the listing to detach. Removing alone does not trigger moderation. Example: ["7c9e6679-7425-40de-944b-e07fc1f90ae7"]. | |
| listing_id | Yes | Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: "adzuna-us-5947308680". |
| Name | Required | Description |
|---|---|---|
| listing | Yes | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) by disclosing the non-obvious state machine effect: adding images re-triggers AI moderation and pushes the listing back to 'pending', while removal does not. It also discloses cost ('free, no credit'), which the annotations cannot convey.
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?
Three tightly packed sentences, front-loaded with the operation before the prerequisite chain. Slight redundancy: the 'max 6 total' and moderation-returns-to-pending facts are restated from the `add` parameter's own schema description.
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?
An output schema exists so return values need no explanation. The description covers scope, limits, prerequisite tool chain, moderation side effect, and cost — everything an agent needs to invoke this correctly on the first attempt.
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?
Schema coverage is 100% and each param already has an example, so the baseline is 3. The description adds genuine meaning on top: `add` keys must originate from request_image_upload with bytes uploaded first, and the add-vs-remove asymmetry in moderation behavior.
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?
States a specific verb pair ('add and/or remove'), the exact resource ('photos'), and the scope ('USER'S OWN existing listings', max 6 total). An agent can immediately separate this from update_listing or create_listing without consulting the schema.
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?
Gives the explicit prerequisite sequence: call request_image_upload per new image, upload the bytes, then pass returned keys in `add`. It also states the hard constraint (max 6 total) and the consequence that triggers it, so there is no ambiguity about when and how to use it versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_listing1 field changedInput schema / additionalPropertiesAdded value: +falsedelete_listing1 field changedInput schema / additionalPropertiesAdded value: +falseget_conversation1 field changedInput schema / additionalPropertiesAdded value: +falseget_entitlements1 field changedInput schema / additionalPropertiesAdded value: +falseget_listing1 field changedInput schema / additionalPropertiesAdded value: +falselist_conversations1 field changedInput schema / additionalPropertiesAdded value: +falselist_my_listings1 field changedInput schema / additionalPropertiesAdded value: +falserenew_listing1 field changedInput schema / additionalPropertiesAdded value: +falsereply_to_conversation1 field changedInput schema / additionalPropertiesAdded value: +falserequest_image_upload1 field changedInput schema / additionalPropertiesAdded value: +falsesearch_listings1 field changedInput schema / additionalPropertiesAdded value: +falsesemantic_search1 field changedInput schema / additionalPropertiesAdded value: +falsesend_message1 field changedInput schema / additionalPropertiesAdded value: +falseset_listing_status1 field changedInput schema / additionalPropertiesAdded value: +falseupdate_listing1 field changedInput schema / additionalPropertiesAdded value: +falseupdate_listing_images1 field changedInput schema / additionalPropertiesAdded value: +falsecreate_listing9 fields changedInput schema / properties / description / descriptionAdded value: +"Full listing text, up to 5000 characters. Facts that fit a `details` key belong in details as well. Example: \"Bright flat on the third floor, five minutes from the metro.\""Input schema / properties / details / descriptionAdded value: +"Vertical-specific attributes. Only these exact keys for the listing's vertical are accepted; any other key is rejected with an error. career: organization_name, employment_type, salary_min, salary_max, years_experience. real_estate: property_room_count, m2_gross, m2_net, building_age, floor_number, heating_type, deposit, dues, is_furnished, is_student_friendly, is_credit_eligible, tapu_status. vehicle: brand, model, vehicle_model_year, vehicle_mileage_km, fuel_type, gear_type, color, damage_status, daily_price, deposit. service: service_category. employment_type is one of full_time, part_time, contract, freelance, internship. is_furnished, is_student_friendly and is_credit_eligible are booleans. real_estate also accepts transaction_type (sale, rent or hire). Example: { \"brand\": \"Toyota\", \"model\": \"Corolla\", \"vehicle_model_year\": 2021, \"vehicle_mileage_km\": 40000, \"fuel_type\": \"hybrid\", \"gear_type\": \"manual\" }."Input schema / properties / images / descriptionAdded value: +"Up to 6 image keys returned by request_image_upload, uploaded before this call. Example: [\"7c9e6679-7425-40de-944b-e07fc1f90ae7\"]."Input schema / properties / location / descriptionPrevious value: -"Listing coordinates as { lat, lon }. A free-text address is NOT accepted — resolve it to coordinates before calling."New value: +"Listing coordinates as { lat, lon }. A free-text address is NOT accepted — resolve it to coordinates before calling. Example: { \"lat\": 48.85, \"lon\": 2.35 }."Input schema / properties / location / properties / lat / descriptionAdded value: +"Latitude in decimal degrees. Example: 48.85."Input schema / properties / location / properties / lon / descriptionAdded value: +"Longitude in decimal degrees. Example: 2.35."Input schema / properties / price / descriptionAdded value: +"Asking price as a plain number in `currency`, with no separators. For a job, use the salary figure and put the range in details.salary_min and details.salary_max. Example: 950."Input schema / properties / title / descriptionAdded value: +"Short headline of the listing, 3-200 characters. Example: \"Two-bedroom flat near the river\"."Input schema / properties / vertical / descriptionAdded value: +"Listing category, which must match the role: career (jobs and CVs), real_estate, vehicle or service. Example: \"vehicle\"."delete_listing1 field changedInput schema / properties / listing_id / descriptionAdded value: +"Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: \"adzuna-us-5947308680\"."get_conversation1 field changedInput schema / properties / thread_id / descriptionAdded value: +"Conversation id (a UUID), taken from list_conversations. Example: \"3f6c2a1e-8b4d-4c7a-9e21-5d0f7a6b1c34\"."get_listing1 field changedInput schema / properties / listing_id / descriptionAdded value: +"Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: \"adzuna-us-5947308680\"."list_conversations2 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum results to return per page, 1-50. Default 20. Example: 10."Input schema / properties / offset / descriptionAdded value: +"How many results to skip, for paging. Default 0. Example: 20 returns the second page when limit is 20."list_my_listings2 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum results to return per page, 1-50. Default 20. Example: 10."Input schema / properties / offset / descriptionAdded value: +"How many results to skip, for paging. Default 0. Example: 20 returns the second page when limit is 20."renew_listing1 field changedInput schema / properties / listing_id / descriptionAdded value: +"Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: \"adzuna-us-5947308680\"."reply_to_conversation2 fields changedInput schema / properties / body / descriptionPrevious value: -"The reply to post into the conversation. Contact routes through Teppek; raw personal details are never exposed."New value: +"The reply to post into the conversation, up to 2000 characters. Contact routes through Teppek; raw personal details are never exposed. Example: \"That time works for me.\""Input schema / properties / thread_id / descriptionAdded value: +"Conversation id (a UUID), taken from list_conversations. Example: \"3f6c2a1e-8b4d-4c7a-9e21-5d0f7a6b1c34\"."request_image_upload2 fields changedInput schema / properties / content_type / descriptionAdded value: +"MIME type of the image file. Example: \"image/png\"."Input schema / properties / file_size / descriptionAdded value: +"Exact file size in bytes, at most 10485760 (10 MB). Example: 2097152 for a 2 MB file."search_listings13 fields changedInput schema / properties / country / descriptionPrevious value: -"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."New value: +"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. Career vertical only. Combine with role + text_query to count/list within a country (e.g. role:\"career_seeker\", country:\"de\", text_query:\"kellner\"); use country alone (no text_query) to get the total number of listings in that country."Input schema / properties / intent_type / descriptionAdded value: +"Which side of the market to return: supply = things on offer (job postings, homes, vehicles, services), demand = people looking for them. Usually unnecessary when role is set. Example: \"supply\"."Input schema / properties / limit / descriptionAdded value: +"Maximum results to return per page, 1-50. Default 20. Example: 10."Input schema / properties / near / descriptionAdded value: +"Radius search around a point, and the way to search real_estate, vehicle and service by place. Works without role or text_query. Example: { \"lat\": 48.85, \"lon\": 2.35, \"radius_km\": 25 }."Input schema / properties / near / properties / lat / descriptionAdded value: +"Latitude in decimal degrees. Example: 48.85."Input schema / properties / near / properties / lon / descriptionAdded value: +"Longitude in decimal degrees. Example: 2.35."Input schema / properties / near / properties / radius_km / descriptionAdded value: +"Search radius in kilometres, up to 200. Default 10. Example: 25."Input schema / properties / offset / descriptionAdded value: +"How many results to skip, for paging. Default 0. Example: 20 returns the second page when limit is 20."Input schema / properties / price_max / descriptionPrevious value: -"Maximum price/salary. Currency-naive raw-number compare (see price_min). If unapplied it appears in meta.ignored_filters."New value: +"Maximum price/salary. Currency-naive raw-number compare (see price_min). If unapplied it appears in meta.ignored_filters. Example: 2000."Input schema / properties / price_min / descriptionPrevious value: -"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."New value: +"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. Example: 500."Input schema / properties / role / descriptionPrevious value: -"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."New value: +"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. REQUIRED whenever text_query is sent; also works with near."Input schema / properties / text_query / descriptionAdded value: +"Keywords matched against listing text. Always send `role` with it: without role the search fails or returns nothing, and vertical alone is not enough. Several words match listings containing ANY of them. Example: \"toyota\"."Input schema / properties / vertical / descriptionAdded value: +"Listing category: career (jobs and CVs), real_estate, vehicle or service. It does not replace `role`: a text_query still needs role. Example: \"vehicle\"."semantic_search1 field changedInput schema / properties / limit / descriptionAdded value: +"Maximum results to return, 1-20. Default 20. Example: 10."send_message2 fields changedInput schema / properties / body / descriptionPrevious value: -"The message to send to the listing owner. Contact routes through Teppek; raw personal details are never exposed."New value: +"The message to send to the listing owner, up to 2000 characters. Contact routes through Teppek; raw personal details are never exposed. Example: \"Hello, can I view the flat this week?\""Input schema / properties / listing_id / descriptionAdded value: +"Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: \"adzuna-us-5947308680\"."set_listing_status1 field changedInput schema / properties / listing_id / descriptionAdded value: +"Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: \"adzuna-us-5947308680\"."update_listing9 fields changedInput schema / properties / currency / descriptionAdded value: +"New ISO-4217 currency code. Rejected with price_locked on a listing published by an assistant. Example: \"EUR\"."Input schema / properties / description / descriptionAdded value: +"New full listing text, up to 5000 characters. Returns the listing to \"pending\". Example: \"Bright flat on the third floor, five minutes from the metro.\""Input schema / properties / details / descriptionAdded value: +"Vertical-specific attributes to change. Only these exact keys for the listing's vertical are accepted; any other key is rejected with an error. career: organization_name, employment_type, salary_min, salary_max, years_experience. real_estate: property_room_count, m2_gross, m2_net, building_age, floor_number, heating_type, deposit, dues, is_furnished, is_student_friendly, is_credit_eligible, tapu_status. vehicle: brand, model, vehicle_model_year, vehicle_mileage_km, fuel_type, gear_type, color, damage_status, daily_price, deposit. service: service_category. employment_type is one of full_time, part_time, contract, freelance, internship. is_furnished, is_student_friendly and is_credit_eligible are booleans. Any details edit returns the listing to \"pending\", so it goes offline until AI moderation clears it. On a listing published by an assistant, salary_min, salary_max, deposit and daily_price are locked and rejected with price_locked. Example: { \"m2_gross\": 90 }."Input schema / properties / listing_id / descriptionAdded value: +"Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: \"adzuna-us-5947308680\"."Input schema / properties / location / descriptionPrevious value: -"New listing coordinates { lat, lon }. Moving a listing re-triggers AI moderation — it returns to \"pending\" until cleared."New value: +"New listing coordinates { lat, lon }. Moving a listing re-triggers AI moderation — it returns to \"pending\" until cleared. Example: { \"lat\": 48.85, \"lon\": 2.35 }."Input schema / properties / location / properties / lat / descriptionAdded value: +"Latitude in decimal degrees. Example: 48.85."Input schema / properties / location / properties / lon / descriptionAdded value: +"Longitude in decimal degrees. Example: 2.35."Input schema / properties / price / descriptionAdded value: +"New asking price as a plain number. Rejected with price_locked on a listing published by an assistant. To change a salary range use details.salary_min and details.salary_max. Example: 950."Input schema / properties / title / descriptionAdded value: +"New headline, 3-200 characters. Returns the listing to \"pending\". Example: \"Two-bedroom flat near the river\"."update_listing_images3 fields changedInput schema / properties / add / descriptionPrevious value: -"Image keys from request_image_upload to attach (upload the bytes first). Each newly-added image is AI-moderated with the listing, so the listing returns to \"pending\" until cleared. Max 6 images total on a listing."New value: +"Image keys from request_image_upload to attach (upload the bytes first). Each newly-added image is AI-moderated with the listing, so the listing returns to \"pending\" until cleared. Max 6 images total on a listing. Example: [\"7c9e6679-7425-40de-944b-e07fc1f90ae7\"]."Input schema / properties / listing_id / descriptionAdded value: +"Listing id, taken from the `id` field of search_listings, semantic_search or list_my_listings results. Example: \"adzuna-us-5947308680\"."Input schema / properties / remove / descriptionPrevious value: -"Image keys currently on the listing to detach."New value: +"Image keys currently on the listing to detach. Removing alone does not trigger moderation. Example: [\"7c9e6679-7425-40de-944b-e07fc1f90ae7\"]."purchase_packagepurchase_packagecreate_listing1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+}delete_listing1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success"
+ ],
+ "type": "object"
+}get_conversation1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+}get_entitlements1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+}get_listing1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "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"
+}list_conversations1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+}list_my_listings1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "listings": {
+ "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"
+ },
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "listings"
+ ],
+ "type": "object"
+}renew_listing1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "listing": {
+ "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"
+ },
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "listing"
+ ],
+ "type": "object"
+}reply_to_conversation1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+}request_image_upload1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "headers_required": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "key": {
+ "type": "string"
+ },
+ "upload_token": {
+ "type": "string"
+ },
+ "upload_url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}search_listings1 field 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"
+}semantic_search1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+}send_message1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+}set_listing_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "listing": {
+ "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"
+ },
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "listing"
+ ],
+ "type": "object"
+}update_listing1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "listing": {
+ "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"
+ },
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "listing"
+ ],
+ "type": "object"
+}update_listing_images1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "listing": {
+ "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"
+ },
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "listing"
+ ],
+ "type": "object"
+}semantic_searchcreate_listingdelete_listingget_conversationget_entitlementsget_listinglist_conversationslist_my_listingsrenew_listingreply_to_conversationrequest_image_uploadsearch_listingssend_messageset_listing_statusupdate_listingupdate_listing_images
Add one secure layer between your agents and this server.