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:

  • 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 ; 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

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations only mark it as non-read-only, non-destructive, and non-idempotent. The description adds substantial behavioral context: the private matching pool, the irreversible nature of contact sending on a match, the email verification anti-abuse mechanism, the isolated contact store, and the 'safe_tags' response. It also clarifies identity handling via authorized session. This goes far beyond the annotations and is exceptionally transparent.

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 long but every section earns its place: the opening purpose, the BEFORE/AFTER CALLING blocks, and the detailed verification flow. It is front-loaded with the core purpose and uses clear headings to separate concerns. This is appropriately detailed for a tool with consent, verification, and irreversible side effects, and it remains highly scannable.

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 nested parameters, a multi-step verification workflow, and sensitive privacy implications. The description covers all required behaviors: pre-call consent, post-call safe_tags, the exact error_code (NEEDS_EMAIL_VERIFICATION), remediation steps, and the platform's never-show-other-needs behavior. With no output schema, it also explains the response structure adequately. Nothing needed to call correctly is omitted.

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?

The schema already describes each parameter, but the description enriches them: it stresses that i_offer is REQUIRED and empty values are blocked by anti-abuse, that contact goes into an isolated store and only email is accepted (other channels go into i_seek/i_offer), and that on match both i_seek/i_offer and email are sent. The verification flow tied to the contact email adds crucial operational meaning not present in the schema.

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 opens with a concrete verb and resource: 'Publish a need (intent) on the user's behalf.' It immediately clarifies that the need joins a private matching pool, distinguishing it from related sibling tools like manage_need or confirm_contact_email. The purpose is unmistakable and specific.

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 pre-call instructions (show i_seek/i_offer, warn about irreversibility of match disclosure, get consent) and post-call actions (relay safe_tags). It also details the email verification workflow, including when to call confirm_contact_email and retry, and explicitly tells the agent not to ask for API keys in favor of OAuth. Usage context and alternatives are fully covered.

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