Teppek

send_message

Message the owner of a Teppek listing on the user's behalf — the primary contact path (there is no price-offer/accept/reject flow). Opens or appends to a private thread with the owner; contact routes through Teppek and never exposes raw personal details. 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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`body`	Yes	The message to send to the listing owner. Contact routes through Teppek; raw personal details are never exposed.
`listing_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.5/5.0

Behavior5/5

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

Discloses substantial behavior beyond annotations: opens or appends to a private thread, routes contact through Teppek without exposing raw personal details, redirects for external-feed listings, and requires Teppek auth with a recoverable error path. Annotations only say readOnly=true/false etc., so this description carries the burdden and does so thoroughly.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: main purpose, thread/privacy behavior, external-feed redirect, and auth requirement. It is front-loaded with the action and avoids restating the tool name or title.

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

Completeness5/5

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

For a messaging tool with auth and external-redirect edge cases, the description covers the critical success and failure behavior, privacy constraints, and connectivity prerequisite. An output schema exists, so detailed return-format documentation is not the description's job. No essential caller-facing behavior is missing.

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

Parameters3/5

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

The description clarifies that listing_id identifies a Teppek listing and adds an edge case for external-feed listings. Body semantics are already covered by the schema description ('Message to listing owner...'), but listing_id lacks a direct schema description and the tool text doesn't compensate with explicit parameter-level detail. The coverage is 50%, so some compensation exists but not complete.

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

Purpose5/5

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

States a specific verb-resource pair: 'Message the owner of a Teppek listing'. It also distinguishes the tool immediately by declaring it 'the primary contact path' and explicitly saying there is 'no price-offer/accept/reject flow'. The private-thread and external-redirect details further separate it from generic messaging tools.

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

Usage Guidelines4/5

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

Gives clear usage context: it is the primary contact path, external-feed listings redirect instead of creating threads, and an anonymous caller gets AUTH_REQUIRED with an authorize_url and should retry. However, it doesn't explicitly contrast with the sibling reply_to_conversation, so an agent must infer whether a reply belongs in this tool or that one.

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

All Teppek tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

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

Naming Consistency4/5

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

Tool Count4/5

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

Completeness4/5

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

Resources

Need Help?