Skip to main content
Glama

Teppek

by com.teppek.mcp

send_message

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesThe message to send to the listing owner. Contact routes through Teppek; raw personal details are never exposed.
listing_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {},
+  "type": "object"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, but the description adds significant behavioral context beyond them: it opens a private thread, routes contact through Teppek without exposing raw personal details, redirects to an external application URL for external-feed listings, and returns an AUTH_REQUIRED error with authorize_url on anonymous calls. This goes well beyond what annotations convey.

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 front-loaded with the core purpose, then each sentence adds a distinct useful item: thread creation, privacy, the reply_to_conversation alternative, external-feed redirect, and auth handling. Despite its length, every sentence earns its place and there is no filler or repetition.

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

Completeness5/5

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

The tool has meaningful complexity: auth requirements, alternate routing paths, and external redirects, all of which are covered. Since an output schema exists, return-value explanation is unnecessary. The description provides an agent with everything needed to decide when to call it and how to handle common failure/edge cases.

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?

Schema description coverage is exactly 50%; body has a full description while listing_id has none. The description indirectly clarifies listing_id by saying the tool is 'identified by the listing', which adds some semantic context, but it doesn't describe the parameter format or value constraints beyond what the schema already provides. This is a mid-range score: the schema handles part of the burden and the description handles the rest only lightly.

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

Purpose5/5

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

The description states a precise action ('START contact with the owner') on a specific resource (a Teppek LISTING), and explicitly positions it as the 'primary FIRST-CONTACT path'. It also carves out what it is not: 'there is no price-offer/accept/reject flow', plus it names the sibling reply_to_conversation for a different use case, making the tool unambiguous.

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

Usage Guidelines5/5

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

The description gives explicit routing guidance: use send_message for first contact, and 'To continue a thread that already EXISTS ... use reply_to_conversation instead.' It also documents external-feed redirects and the auth-required retry flow, so an agent knows exactly when and how to handle edge cases.

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

All Teppek toolsInspect
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