Skip to main content
Glama

Pairoa

by com.pairoa.mcp
OverviewDiscussionsAdmin

Publish a need

publish_need

Publish a "need" (intent) on the user's behalf. The need joins a private matching pool — no other user can see it unless the platform AI judges a match.

BEFORE CALLING:

  • For dating: For dating, confirm five facts with the user, then include these labels (English or Chinese), one per line or separated by semicolons: in i_offer: My age / 本人年龄 (18–99), Self-stated gender / 自述性别 (man, woman, nonbinary, other); in i_seek: Partner genders / 希望对方性别 (explicit genders or any), Partner age range / 希望对方年龄 (e.g. 22–28), Relationship intent / 关系目的 (long-term relationship, casual dating, friends first). Do not infer missing facts or resolve contradictory statements on the user's behalf.

  • Show the user the exact i_seek / i_offer you'll send.

  • Tell them that on a match, BOTH the need text (i_seek / i_offer) AND their contact are sent to the matched party — and can't be unsent afterward (like an email you've sent). Leave out anything they wouldn't want a matched stranger to have.

  • Get explicit consent.

AFTER CALLING:

  • The response includes 'safe_tags' (2-6 short tags) that will appear in match notification emails. Relay them back to the user.

  • In normal remote MCP connectors, identity is handled by OAuth — do NOT ask the user to paste or store an API key/token in client config. Low-level legacy HTTP/API clients may receive an 'anonymous_token' from the web API, but this MCP connector should rely on its authorized session.

CONTACT EMAIL VERIFICATION (v0.18.2 — IMPORTANT):

  • Pairoa requires the contact email to be verified the FIRST time it's used with the current connection/account.

  • If the contact email hasn't been verified yet, this tool returns error_code = "NEEDS_EMAIL_VERIFICATION". A 6-digit code is automatically emailed to the contact email at the same time.

  • When you see NEEDS_EMAIL_VERIFICATION:

    1. Tell the user a code was sent to <contact_email>; ask for the 6 digits.

    2. Call confirm_contact_email({ email, code }).

    3. Retry publish_need with the same inputs — it'll go through.

  • Same connection/account + same email = subsequent publishes don't ask for the code again.

  • This is the platform's anti-abuse measure: prevents someone from filling someone else's email in contact (the code goes to the real owner, the attacker can't get it).

The platform never shows other users' needs to you — only your own and any matches you produce.

Input Schema

NameRequiredDescriptionDefault
i_seekYesNatural language: what you're looking for. Include time constraints if any.
contactYesContact info goes into a separate, isolated store (kept out of the need pool). Only email is accepted — put any other channel (Telegram, X, LinkedIn, etc.) in your i_seek / i_offer text instead. On a match the email is sent to the matched party together with your i_seek / i_offer text — and can't be unsent afterward.
i_offerYesNatural language: who you are and what you bring. REQUIRED — empty i_offer is blocked by anti-abuse rules. For dating, see the five user-confirmed facts in publish_need instructions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / i_offer / description
      Previous value: -"Natural language: who you are and what you bring. REQUIRED — empty i_offer is blocked by anti-abuse rules."New value: +"Natural language: who you are and what you bring. REQUIRED — empty i_offer is blocked by anti-abuse rules. For dating, see the five user-confirmed facts in publish_need instructions."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description adds substantial behavior beyond annotations: the private matching pool, AI-gated visibility, irreversible sharing of need text and contact on a match, safe_tags in the response, OAuth identity handling, and the email-verification anti-abuse flow. These are exactly the operational and risk details an agent needs before calling a non-read-only, open-world publish tool.

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

Conciseness4/5

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

The description is well structured and front-loads the purpose before prerequisites, consent, post-call behavior, and verification recovery. It is somewhat long and includes minor repetition/version noise, but almost every section earns its place because the consent and verification flow is genuinely needed.

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 mutation tool with nested contact data, open-world matching, no output schema, and an email-verification branch, the description is complete. It covers prerequisites, consent, privacy implications, result behavior (safe_tags), and the exact recovery path via confirm_contact_email.

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

Parameters5/5

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

Schema coverage is 100%, but the description still adds meaningful parameter semantics: required dating facts and label formats for i_seek/i_offer, explicit handling of contact as an isolated email-only store, and guidance to put other channels in the need text. This goes well beyond what the schema itself provides.

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 specific verb and resource: publish a need/intent on the user's behalf into a private matching pool. It also clarifies the visibility model (no other user sees it unless the platform AI judges a match), which distinguishes this from passive listing or direct 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?

The BEFORE CALLING section gives clear prerequisites: confirm dating facts, show the exact i_seek/i_offer, explain irreversible sharing on match, and obtain explicit consent. It also routes the agent to confirm_contact_email on the NEEDS_EMAIL_VERIFICATION error, though it does not explicitly contrast this tool with manage_need or other need-management siblings.

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

All Pairoa toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources