Pairoa
Server Details
Your AI meets theirs before you do — private matching for needs, offers, and opportunities over MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 8 of 8 tools scored.
Each tool targets a distinct operation: account claiming, email verification, invite creation, match decline, need management, match polling, need publishing, and cross-device recall. No two tools overlap in purpose.
All tool names follow a consistent verb_object pattern in lowercase_snake_case (e.g., claim_account, publish_need, recall_by_email). The verbs are clear and descriptive.
With 8 tools, the server covers all essential operations for need publishing, matching, and account management without unnecessary duplication or bloat.
The tool set fully supports the core workflow: publishing needs, verifying emails, managing needs, retrieving matches, declining matches, and cross-device recall. No obvious gaps.
Available Tools
8 toolsclaim_accountClaim a persistent pseudonymous accountAInspect
Two-step: claim a persistent pseudonymous account by email.
Step 1: call with { step: 'send_code', email: 'user@example.com' } — a 6-digit code is emailed. Step 2: call with { step: 'verify_code', email: 'user@example.com', code: '123456' } — claims the account and merges any anonymous needs the caller has into the new identity.
After claim, the same email used in future contact fields auto-links to this identity.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Required when step='verify_code'. | |
| step | Yes | ||
| Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the full burden. It discloses that the tool sends an email with a 6-digit code, requires sequential steps, and merges anonymous needs into the new identity after verification. It also mentions future auto-linking of the email. All critical behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear step labels (Step 1, Step 2) and front-loads the two-step nature. It avoids unnecessary words but could be more structured (e.g., bullet points). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the multi-step process and no output schema, the description fully explains the flow: initial call to send code, then verify with code, and the outcome (account claimed with merged needs and future auto-link). It does not cover error handling, rate limits, or response structure, but for a tool of this complexity it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'code' has a description). The description compensates by explaining the 'step' parameter values ('send_code' and 'verify_code') and the role of 'email' as the user's email. It also clarifies that 'code' is the 6-digit code from the email. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Claim a persistent pseudonymous account' and description clearly state the verb 'claim' and resource 'persistent pseudonymous account'. The two-step process is described, distinguishing it from sibling tools like 'confirm_contact_email' which confirm existing emails rather than claiming new accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step instructions for when to use each step (send_code vs verify_code). It does not, however, discuss when not to use the tool or mention alternatives (e.g., for password-based authentication). This is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
confirm_contact_emailConfirm the contact email by 6-digit codeAInspect
Confirm the contact email by entering the 6-digit code the user got in their inbox (v0.18.2).
WHEN TO CALL:
publish_need returned error_code = "NEEDS_EMAIL_VERIFICATION", AND the user told you the 6-digit code.
WHAT IT DOES:
Verifies the code and marks this connection/account + email as verified.
Subsequent publish_need calls with the same email no longer ask for the code.
AFTER CALLING:
Retry the original publish_need with the same i_seek / i_offer / contact.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The 6-digit code the user got in their inbox. | |
| Yes | The contact email the user gave you in publish_need. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that the tool marks the email as verified and subsequent publish_need calls won't ask for code. Annotations already indicate it's not readonly, but description adds specific mutation details without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with clear sections (WHEN TO CALL, WHAT IT DOES, AFTER CALLING). Every sentence is value-adding and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple verification tool with no output schema, the description covers trigger conditions, behavior, and post-call actions. Input schema is fully documented. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add new meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool confirms a contact email using a 6-digit code. It distinguishes from siblings by tying usage to publish_need's error, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly defines when to call: after publish_need returns NEEDS_EMAIL_VERIFICATION and user provides code. Also specifies retrying publish_need after, providing clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_invite_linkCreate a shareable Pairoa invite linkARead-onlyIdempotentInspect
Create a shareable Pairoa invite link for the current user. Returns { ref, url, share_text }.
ONLY works after the user has claimed an account (claim_account). Otherwise returns AUTH_REQUIRED — guide them to claim first (claiming happens automatically on their first match).
The 'share_text' is ready to forward AS-IS — to a Slack/Discord/WeChat group, a tweet, or a DM. Relay it to the user so they can paste it wherever they like; offer the bare 'url' too if they only want the link.
Invites carry NO reward and are purely a convenience for word-of-mouth. Don't over-promote or nag. We do not track who the invitee is — only a private count of how many people a link brought in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotation readOnlyHint=true by stating it 'creates' a link, implying mutation. While it adds useful context (no reward, no tracking), the contradiction is critical and scores 1 per rubric.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively long but every sentence adds value (purpose, prerequisite, return format, behavioral notes). Could be slightly more concise but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and existing annotations, the description fully covers purpose, prerequisite, return format, and behavioral nuances. No gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), so baseline is 4. Description adds no param info but does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an invite link for the current user and distinguishes it from siblings like claim_account by specifying the prerequisite. The verb 'create' and resource 'invite link' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite (claim_account) and provides guidance on what to do if AUTH_REQUIRED error occurs. Also advises against over-promotion, giving clear context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decline_matchDecline (or report) a matchAInspect
Mark a match as not interested, OR report it as spam / inappropriate. Once declined, the platform won't surface this pair again. Note: from the moment the match was made, the other party already has the user's need text + contact — declining stops new surfacing on our side but can't pull back what they already received.
Use reason='report_spam' or 'report_inappropriate' when the match looks like an abuse attempt; reported publishers are reviewed and repeat offenders are removed.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| reason | No | ||
| match_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing important behavioral traits: 'Once declined, the platform won't surface this pair again' and warns that the other party already has the user's information and declining cannot undo that. It also explains the review process for reported publishers, adding valuable context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the main action stated upfront in the first sentence. It uses two short paragraphs, the second providing specific guidance on the 'reason' parameter. No extraneous information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema), the description covers the key aspects: purpose, effect on the match, reporting process, and caveat about information shared. It does not discuss idempotency or return values, but these are not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning primarily for the 'reason' parameter, specifying when to use 'report_spam' or 'report_inappropriate'. The 'match_id' parameter is inherently clear from its name, and 'note' is implied to be optional text. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Mark a match as not interested, OR report it as spam / inappropriate.' It specifies the verb (decline/report) and the resource (match). Among the sibling tools, none serve a similar function, so the tool is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines for when to use the tool: to decline or report a match. It also specifies when to use the 'reason' parameter with values like 'report_spam' or 'report_inappropriate' for abuse attempts. However, it does not explicitly state when not to use the tool or mention alternative tools, which is acceptable given that no sibling tool serves a similar purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_needManage an existing need (edit / close / status)ADestructiveInspect
Manage an existing need:
action='status': Get current state (active/closing/closed, remaining TTL, total matches, current safe_tags).
action='close': End the need. Closing erases the need's raw text + embedding immediately. But anything that already matched was already sent to the other party — closing can't pull that back (it stays in their match record, like an email you've already sent).
action='edit': Change i_seek / i_offer / safe_tags. Changing content forces a re-extraction of safe_tags (unless you pass safe_tags explicitly) and re-runs matching against the active pool.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| i_seek | No | ||
| i_offer | No | ||
| need_id | Yes | ||
| safe_tags | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond annotations: close erases raw text and embedding but cannot retract sent matches; edit triggers re-extraction and re-matching. This adds value beyond the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with bullet points for each action. The first bullet is lengthy but informative. Almost every sentence adds value, though some repetition could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains return values for status (state, TTL, matches, safe_tags) but not for close or edit. There is no output schema, so return values for close/edit are missing, leaving agents to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by explaining how each action uses parameters (e.g., edit changes i_seek/i_offer/safe_tags, status returns state). However, it does not explicitly state which parameters apply to which actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool manages an existing need with three specific actions (edit/close/status). The description elaborates each action's purpose, distinguishing it from siblings like publish_need which creates a need.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use each action (status, close, edit) and explains consequences like data erasure on close. However, it does not explicitly state when not to use the tool or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
poll_matchesPoll matches for your needsARead-onlyIdempotentInspect
Fetch matches for the caller's needs. Call this when the session starts, or when the user asks "any matches?". Returns full match content including the counterparty's i_seek/i_offer, contact info, and the judge's reasoning — only for needs owned by the caller. Each match also includes a 'safety' field — a fraud-prevention notice from Pairoa. ALWAYS show it to the user verbatim, right after you present the match. Each match also carries 'my_contact' = the email (and any extra) the user published THAT need with; it's the user's own data (not the counterpart's), so you can safely use it to group or split the user's matches by which of their emails published the need.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of matches to return. Default 50. | |
| need_id | No | If provided, only return matches for this need. Otherwise return all matches for the caller's identity. | |
| unviewed_only | No | Only return matches the user hasn't opened yet. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly and idempotent. The description confirms reads only, discloses scope (only caller's needs), and explains fields like 'safety' and 'my_contact' with behavioral implications. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose and usage timing. It includes necessary details but is somewhat verbose. However, every sentence adds value, and structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description fully explains return content (counterparty info, reasoning, safety, my_contact) and usage rules. Combined with high schema coverage and annotations, the tool is completely documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add new parameter semantics beyond what the schema already provides. It mentions optional filtering but echoes schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch matches for the caller's needs' and specifies when to call ('when the session starts, or when the user asks "any matches?"'). It details the return content and distinguishes from siblings (none fetch matches). The verb 'poll' combined with 'matches' and context clarifies the tool's unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises when to call the tool and gives a mandatory instruction to display the 'safety' field verbatim. While it lacks explicit exclusion of alternatives, the sibling list shows no alternative for fetching matches, so the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_needPublish a needAInspect
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:
Tell the user a code was sent to ; ask for the 6 digits.
Call confirm_contact_email({ email, code }).
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.
| Name | Required | Description | Default |
|---|---|---|---|
| i_seek | Yes | Natural language: what you're looking for. Include time constraints if any. | |
| contact | Yes | Contact 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_offer | Yes | Natural language: who you are and what you bring. REQUIRED — empty i_offer is blocked by anti-abuse rules. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behaviors beyond annotations: needs join a private pool, contact is sent to matched party and cannot be unsent, email verification anti-abuse process. No contradiction with annotations (readOnlyHint=false, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, front-loaded with purpose. Every sentence is valuable, but the description is somewhat lengthy. Could be slightly trimmed without loss, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested object, email verification flow, multiple user-facing steps), the description fully covers all aspects: purpose, usage steps, error handling, authentication guidance, and post-call actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant value: clarifies that contact info is stored separately, only email is accepted, and i_offer is required and anti-abuse enforced. Adds context about consequences of sending contact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool publishes a 'need' (intent) on the user's behalf, joining a private matching pool. This is a specific verb+resource that distinguishes it from sibling tools like manage_need or poll_matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides extensive pre- and post-call instructions: showing user the exact i_seek/i_offer, obtaining consent, relaying safe_tags, and handling email verification with a fallback to confirm_contact_email. Explicitly tells when to use and not to use (e.g., no API key storing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recall_by_emailRecall my needs & matches by emailAInspect
Recall the user's OWN needs and matches by their contact email — for when they're on a DIFFERENT AI client (or reconnected) than the one they published from, so poll_matches shows nothing even though they did publish.
Flow:
Call with just { email }. If this client hasn't verified that email lately, you'll get error_code "NEEDS_EMAIL_VERIFICATION" and a 6-digit code is emailed to it. Ask the user for the code, then call again with { email, code }.
Once verified, this client gets a 30-day pass: within 30 days, calling with just { email } returns results without a new code.
Returns the user's needs (active) and ALL their matches (including matches for needs they later closed), with each match's counterpart contact + why_match. Each match has a 'safety' field — relay it to the user VERBATIM (same rule as poll_matches).
Use this when the user says "I published from another device / browser", "find my matches by email", or when poll_matches is empty but the user is sure they published. After recalling, you can manage those needs (manage_need / decline_match) for the duration of the 30-day pass.
This is read + manage, NOT account takeover: the pass is temporary (30 days) and never permanently merges identities.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | The 6-digit code from the user's inbox. Omit on the first call; on NEEDS_EMAIL_VERIFICATION, ask the user for it and call again with it. | |
| Yes | The contact email the user originally published with. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the two-step verification process, 30-day pass, and that the tool is read+manage, not read-only despite readOnlyHint=false. Mentions safety field must be relayed verbatim, matching poll_matches behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with flow and return description, but slightly verbose. Front-loaded with core purpose and usage. Every section earns its place, though could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by detailing return types (needs, matches, safety field, why_match). Explains multi-call flow, error handling, and session duration. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for both parameters. Description adds context: email is the original publishing contact, code is omitted first call and used on retry after verification. Beyond schema, explains flow semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it recalls the user's own needs and matches by email, targeted at cross-device scenarios where poll_matches returns empty. It distinguishes from sibling tools like poll_matches and manage_need, and the title reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use scenarios (different client, reconnected, poll_matches empty) and step-by-step flow including verification error handling. Explicitly states it is not account takeover and provides usage after recall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!