Pairoa
Server Details
People matching through your AI — private, agent-to-agent; details shared only on a match.
- 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.6/5 across 8 of 8 tools scored. Lowest: 4/5.
Each tool has a distinct purpose: account claiming, email verification, invite creation, match decline, need management, match polling, need publishing, and cross-device recall. Even though claim_account and confirm_contact_email both involve email verification, they serve different roles in the workflow and are clearly differentiated by context.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., claim_account, decline_match, poll_matches). The verbs are specific and descriptive, making the intent of each tool immediately clear.
With 8 tools, the server is well-scoped for its purpose of managing pseudonymous need-matching. Each tool covers a necessary operation without unnecessary duplication or bloat.
The core workflow (publish, match, manage, decline, recall) is covered, but there is a notable gap: no tool to list all of a user's own published needs from the current client. manage_need requires a need ID, and poll_matches returns only matches, not the need list itself.
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 have readOnlyHint=false and destructiveHint=false, so no contradiction. The description adds behavioral context beyond annotations: the two-step flow, email sending, merging of anonymous needs, and future auto-linking. No hidden side effects are omitted, and the description aligns 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 concise: 6 short lines. It front-loads the overall purpose and then breaks down the two steps efficiently. Every sentence adds value; no filler.
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 the description should ideally mention the return value or success indication. However, the tool is a mutating command, and the description provides enough procedural detail for the agent to use it correctly. A brief note about response (e.g., 'returns a success token') would improve completeness.
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%, but the description compensates well by giving concrete JSON examples for each step and explaining the purpose of the 'code' parameter. It clarifies the dependency between 'step' and 'code', and adds the merge effect for 'verify_code'.
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?
Clearly states the tool claims a persistent pseudonymous account via a two-step email verification process. It names the specific verb 'claim' and the resource 'persistent pseudonymous account'. The sibling tools (e.g., confirm_contact_email, create_invite_link) are distinct, so no confusion.
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 explicit step-by-step guidance: first call with step='send_code', then with step='verify_code' and code. It also explains the merge effect. However, it does not mention when not to use this tool or compare to alternatives, but the usage is clear enough.
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, marks (anonymous_token | identity, 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?
Annotations are all false; description adds value by explaining that the tool verifies the code, marks (anonymous_token, identity, email) as verified, and that subsequent publish_need calls with the same email will not ask for the code. No contradictions.
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 well-structured with clear sections (WHEN TO CALL, WHAT IT DOES, AFTER CALLING). Each sentence is necessary and directly contributes to clarity. No wasted words.
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 simplicity (2 parameters, no output schema), the description fully covers purpose, usage conditions, behavior, and post-call actions. It is complete and leaves no ambiguity.
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?
Input schema has 100% coverage with descriptions for both parameters. The description adds context that the email must be the one used in publish_need, which aids understanding beyond the schema. A minor but useful addition.
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: confirm the contact email by entering a 6-digit code. It distinguishes from siblings by tying execution to publish_need's error_code and specifying its role in the email verification process.
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?
Explicit WHEN TO CALL section: only call when publish_need returns NEEDS_EMAIL_VERIFICATION and user provides the code. Also provides AFTER CALLING guidance to retry the original publish_need with the same data.
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?
Annotation contradiction: readOnlyHint=true but description states 'Create' which implies a write operation. This fundamental inconsistency leads to a score of 1. Otherwise, the description adds context about no rewards and no tracking.
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 multiple sentences, each providing essential information. Slightly verbose but clear and front-loaded with the core action. Could be trimmed slightly but still efficient.
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 and no output schema, the description covers all necessary aspects: purpose, prerequisites, error handling, return value, and social usage rules. Complete for a simple 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, so baseline is 4. The description adds value by detailing the return object fields ({ref, url, share_text}) and usage of share_text, which compensates for the lack of parameters.
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?
Clearly states the verb 'Create', the resource 'shareable Pairoa invite link', and the target 'for the current user'. Distinct from sibling tools like claim_account and 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?
Explicitly states the prerequisite ('ONLY works after claim_account'), the error condition (AUTH_REQUIRED), and how to handle it. Additionally, advises against over-promotion, providing clear guidance on when and how to 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 discloses that declining cannot retract already shared information and that reported publishers are reviewed. Annotations (destructiveHint=false) align, and the description adds valuable behavioral context.
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 two focused paragraphs with no unnecessary information. Front-loaded with core purpose, followed by specific reporting guidance.
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 3-parameter tool with no output schema, the description fully covers behavior, side effects, and reporting mechanism. An agent can use it correctly without additional context.
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 for the 'reason' parameter (explains enum values and their intent) but does not clarify 'match_id' or 'note'. Baseline 3 due to partial compensation.
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 marks a match as not interested or reports it as spam/inappropriate, and explains the consequence (no longer surfaced). It's specific and distinct from siblings like 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?
The description provides clear guidance on when to use report reasons, including the context that reporting leads to review. It lacks explicit comparison to other tools but offers sufficient context for proper use.
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 provides rich behavioral context beyond annotations: closing erases raw text/embedding but retains matched records (like sent emails), editing forces re-extraction and re-runs matching. This aligns with destructiveHint and openWorldHint.
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 well-structured with bullet points for each action, concise yet comprehensive, with no redundancy or filler. 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 tool's complexity (multiple actions with side effects) and no output schema, the description fully covers all actions, their consequences, and parameter behavior. It leaves no major gaps for an agent to choose and invoke the tool correctly.
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?
Despite 0% schema coverage, the description adds meaning to parameters: action values are explained, i_seek/i_offer are referenced, and safe_tags behavior (re-extraction unless explicitly passed) is detailed. need_id is not described, but the UUID format is in 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 description clearly states that the tool manages an existing need with three distinct actions (status, close, edit), each with specific effects. It distinguishes itself from siblings like publish_need and decline_match by focusing on existing needs.
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 implies when to use each action (status for checking state, close to end a need, edit to modify content) but does not explicitly state when to avoid this tool or mention alternatives like publish_need for creation.
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 already indicate read-only and idempotent behavior. The description adds crucial context: returns full match content including safety field (with instruction to show verbatim) and explains the 'my_contact' field. 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 somewhat lengthy but every sentence adds value. It is front-loaded with the core function and usage triggers, then details return fields. Could be slightly more terse, but effectively structured.
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 values (full match content, safety field, my_contact). It covers behavioral aspects (show safety verbatim) and usage context (session start, specific need filtering). Fully complete for an AI agent.
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 3 is appropriate. The description does not add extra detail about parameters beyond what the schema provides (limit, need_id, unviewed_only are well-documented in schema). The description focuses more on return values and usage patterns.
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 fetches matches for the caller's needs and provides specific usage triggers (session start, user asking for matches). It distinguishes from sibling tools like decline_match and manage_need by focusing on polling rather than modifying or creating.
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 explicitly says when to call (session start, when user asks for matches). While it doesn't spell out when not to call, the sibling tools list covers alternative actions, and the context is clear enough for an AI agent.
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.
The response also includes an 'anonymous_token' if the user has no account yet — your client MUST persist this token securely (e.g. in client config) for follow-up calls.
CONTACT EMAIL VERIFICATION (v0.18.2 — IMPORTANT):
Pairoa requires the contact email to be verified the FIRST time it's used with a given anonymous_token (or identity).
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 <contact_email>; ask for the 6 digits.
Call confirm_contact_email({ email, code }).
Retry publish_need with the same inputs — it'll go through.
Same anonymous_token + 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?
The description goes well beyond annotations (readOnlyHint=false, etc.) by disclosing that needs join a private pool, contact and text are sent on match and cannot be unsent, and email verification is required. It also explains anti-abuse measures and response contents, providing full behavioral context.
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 well-structured with clear sections (BEFORE, AFTER, CONTACT VERIFICATION) and is front-loaded with purpose. While lengthy, the detail is warranted given the complexity. Every sentence adds value, though minor tightening could improve conciseness.
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?
Despite no output schema, the description fully explains the response contents (safe_tags, anonymous_token) and error handling. It covers the complete flow including prerequisites, post-call actions, and edge cases (email verification), making the tool understandable without additional documentation.
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 all parameters. The description adds significant value by clarifying the 'contact' field limitations (only email, other channels go in text) and emphasizing the irreversible nature of the action. This extra context enhances parameter understanding.
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 'Publish a need (intent) on the user's behalf,' using a specific verb and resource. It distinguishes from sibling tools like 'manage_need' and 'recall_by_email' by detailing the matching pool and unique workflow.
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 BEFORE CALLING and AFTER CALLING sections with actionable steps (show user text, get consent, relay safe_tags). It also explains the email verification flow with error handling. However, it lacks explicit guidance on when not to use this tool versus alternatives.
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?
Beyond annotations (readOnlyHint=false, etc.), the description discloses sending verification emails, 30-day pass, return of safety field, and explicitly states 'read + manage, NOT account takeover.'
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 heading, step-by-step flow, and bullet-worthy notes. Every sentence serves a purpose, no fluff.
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?
Complete for a tool with 2 parameters and no output schema. Explains return content (needs, matches, safety), verification flow, and ties to sibling tools (manage_need, decline_match).
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 descriptions cover both parameters with details (email format, code pattern). The description adds value by explaining the two-call flow (first call without code, second with) and context for the code parameter.
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 'Recall the user's OWN needs and matches by their contact email' and distinguishes from siblings like poll_matches by specifying the scenario of a different client.
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?
Explicit when-to-use guidance: '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.' Also explains flow and error handling.
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!