Favor

Favor lets browser agents turn Telegram work posts into trusted marketplace matches and reviewable deal drafts, while humans keep control of publishing and payments.

Comment

Favor: Turn Telegram Work Into Trusted Deals

Inspiration

Online work already happens in Telegram. A photographer shows recent shoots in a channel. A tutor finds students in a neighborhood chat. A lawyer gets clients through recommendations. A designer sends a portfolio in private messages. Clients post requests in communities and ask friends whom they trust.

The conversation is easy. The handoff into actual work is not. Useful posts disappear in the feed, terms stay scattered across messages, and a completed job often leaves no portable proof beyond "thank you" in an old chat. People do not need another place to talk. They need a reliable way to turn existing conversations into work that is searchable, structured, and trustworthy.

That is why we built Favor: a Telegram-native marketplace where a post can become an opportunity, an opportunity can become a deal, and a completed deal can become reputation.

What it does

Favor serves both sides of online work. A professional can turn a public Telegram post into a service offer, then add a price, deadline, category, portfolio, and terms. A client can turn a post describing what they need into a client request. People can search both types, inspect profiles, ratings, reviews, portfolios, and completed work, then manage the deal within the Telegram flow. Optional on-chain escrow in TON or USDT can protect payment when both sides want it.

For the WebMCP Challenge, we made this live workflow actionable for browser agents through four focused tools:

  • favor_search_contracts searches public service offers and client requests by text, category, budget, deadline, rating, and escrow support.
  • favor_get_contract returns one listing's terms, author reputation, reviews, completed-deal signals, and Favor URL.
  • favor_read_telegram_post reads a public Telegram work post through Favor's existing import pipeline and returns its text and media metadata.
  • favor_prepare_contract_draft turns the result into a draft with a Telegram review link that expires after 24 hours.

A user can ask: "Find a TikTok promotion specialist under $300 who supports escrow, compare the strongest options, and turn my Telegram brief into a client request." The agent handles discovery and preparation. The user checks every field and decides whether to publish.

How we built it

Favor is a production Next.js 16 and React 19 application written in TypeScript, with Prisma and PostgreSQL, Zod validation, a Telegram Mini App and bot, and TON infrastructure for optional escrow. The product, its users, marketplace, deals, reputation system, and Telegram import flow existed before this challenge.

During the challenge, we added a WebMCP extension using the imperative API. An application-level provider detects document.modelContext and registers the four tools once. This is progressive enhancement: without WebMCP, Favor works exactly as before. Registration failures are isolated, and React lifecycle cleanup removes registered tools safely.

The tools reuse Favor's production clients and APIs instead of duplicating product logic. Inputs have strict JSON schemas and are validated again with Zod at execution time. Contract identifiers must match Favor's generated slug format and are URL-encoded before requests. Cancellation signals reach the network layer, so stopping a tool stops its underlying work.

Trust boundaries are explicit. Public discovery tools declare readOnlyHint: true. Listings, reviews, and imported Telegram text declare untrustedContentHint: true, because user-written content must never become agent instructions. Search is rate-limited and scans a bounded candidate set.

The only state-changing WebMCP tool creates a visible, expiring draft for human review. It cannot publish a contract, start a deal, fund escrow, release payment, or issue a refund. Those actions remain in explicit user-controlled Favor flows.

Challenges we ran into

The hardest problem was not registering a tool. It was deciding where an agent's authority should end.

Turning a loose Telegram post into structured work is exactly where an agent helps, but the same flow touches identity, publishing, agreements, and eventually money. Full autonomy would look impressive in a demo and be wrong for a real marketplace. We designed the 24-hour review handoff so the agent removes repetitive work without impersonating the user or committing funds.

Marketplace text and reviews created a second challenge. They are valuable context, but also untrusted user content. We had to keep responses concise, label content correctly, restrict slugs, validate inputs twice, rate-limit search, and preserve cancellation across every layer.

Finally, this was not a greenfield prototype. We integrated WebMCP into a live Telegram product without breaking unsupported browsers or creating duplicate business rules that could drift from production.

Accomplishments that we're proud of

The demo uses the live Favor product, not a scripted chatbot over sample data. It shows Favor's four registered tools and a successful production marketplace search; we also verified live contract inspection and Telegram-post import. The private 24-hour draft handoff is implemented, while WebMCP registration, execution, cancellation, and cleanup are covered by automated tests. We deliberately did not create test data in the production account used for the read-only demo.

The tools are small enough to be safe and composable, but together cover the tedious path from "I need help" to "this is ready for me to approve." Favor remains fully usable without WebMCP, while a compatible browser gains structured capabilities immediately.

We are also proud of the boundary we did not cross. Every public or financial commitment stays human-controlled. Automated tests cover feature detection, registration, execution, cancellation, cleanup, and partial registration failure, alongside Favor's wider contract test suite and production build.

To be transparent about challenge scope: Favor predates the event. The challenge-period work is the WebMCP runtime, four production-backed tools, application-level registration, schemas and safety annotations, tests, and documentation that make the existing product agent-ready. The exact source footprint and production checks are documented in the public challenge guide.

What we learned

The best agent integration is not a second interface pasted over a product. It is a precise set of capabilities attached to the product's existing source of truth.

Small tools compose better than one oversized "do everything" tool. Search, inspect, import, and prepare each have a clear contract and permission level. We also learned that human approval is not friction to eliminate when identity, reputation, or money is involved. It is part of the product value.

WebMCP can make a browser agent useful inside a real application without making the application dependent on the agent. That balance let us ship the extension into Favor instead of maintaining a separate hackathon demo.

What's next for Favor

Next we will improve intent-aware ranking and comparisons, expand the reputation signals agents can explain, and learn from real search-to-draft journeys. We want more kinds of Telegram posts to enter Favor while preserving the visible review step.

As WebMCP evolves, we plan to expose more preparation and decision support around proposals and deal terms. Publication, deal acceptance, and every escrow action will continue to require explicit human approval.

Try the live product at favor.deals or open @FavorDealsBot in Telegram.

Built With

Share this project:

Updates

Submission history