Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pingrep-mcp-server search for AI representatives in healthcare"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Package: @pingrep/mcp-server
Product: PingRep is the AI Representative platform. Always on.
Docs | |
Official CLI | https://github.com/pingrep/pingrep ( |
Product | |
App |
This repository is the official PingRep product MCP server for Claude Desktop, Cursor, and other MCP clients. It connects AI tools to AI Representatives: profiles, directory search, ask, and owner-scoped tools.
npx -y @pingrep/mcp-server
# or
npm install -g @pingrep/mcp-serverRequires Node.js 18+.
Related MCP server: Dovetail MCP Server
{
"mcpServers": {
"pingrep": {
"command": "npx",
"args": ["-y", "@pingrep/mcp-server"],
"env": {
"PINGREP_API_KEY": "sk_live_your_key_here",
"PINGREP_BASE_URL": "https://api.pingrep.com"
}
}
}
}Public / discoverable tools include get_profile, ask_ai_rep, search_profiles, and save_contact (auth). Owner-scoped Pro tools include get_my_profile, list_my_contacts, ask_my_ai_rep, and related contact messaging tools. Full list: Available tools.
npm install
npm run build
npm test
npm startnpm publish uses GitHub Actions trusted publishing on version tags (v*). See .github/workflows/release.yml.
Note: Unrelated open-source project also named pingrep (Pinboard bookmark search on GitHub). This repo is the official PingRep product.
Ask a PingRep AI Representative a question about their professional background, expertise, or services. The AI Rep answers on behalf of the profile owner based on their professional identity. Returns the answer and suggested follow-up questions.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The question to ask the AI Representative | |
| profileId | Yes | The profile identifier (UUID or username slug) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description complements the readOnlyHint annotation by explaining that the AI Rep answers on behalf of the profile owner, a read-like behavior. It also discloses that the tool returns the answer and suggested follow-up questions, adding useful behavioral context beyond the 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?
Two sentences front-load the core action and include the return value. Every sentence contributes meaning with 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?
For a tool with 2 well-documented parameters and a readOnlyHint annotation, the description adequately covers purpose and output. It could mention that the AI Rep is a simulation, but overall it is sufficient.
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 100% schema coverage, the schema already documents both parameters. The description adds value by implying that questions should focus on professional background, expertise, or services, providing semantic guidance that helps the agent formulate appropriate queries.
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 action (ask), the resource (AI Representative), and what it does (answers based on professional identity). However, it does not explicitly differentiate from sibling tools like 'ask_my_ai_rep' and 'ask_contact_ai_rep', which could cause confusion about which rep to query.
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 no guidance on when to use this tool versus its siblings (e.g., 'ask_my_ai_rep' or 'ask_contact_ai_rep'). It lacks exclusions, prerequisites, or contextual hints for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask a saved contact's PingRep AI Representative a question.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Question for the AI Representative | |
| contactId | Yes | Saved contact ID from list_my_contacts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description does not contradict it. However, no additional behavioral details (e.g., response format, latency, streaming) are disclosed beyond what annotations provide.
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?
Single sentence, front-loaded with verb and resource, 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 two params, no output schema, and readOnlyHint, the description covers the core purpose. Minor missing: expected return behavior or any prerequisites, but still sufficient for a simple query 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?
Schema coverage is 100%, with both parameters already well-described. The description adds no extra semantic context beyond what the schema provides, so baseline score applies.
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 action (ask a question), resource (saved contact's PingRep AI Representative), and differentiates from siblings like ask_my_ai_rep and ask_ai_rep.
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?
Usage context is implied (requires a saved contact from list_my_contacts), but no explicit when-to-use or when-not-to-use guidance is provided despite siblings having similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the authenticated user's own PingRep AI Representative a question.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Question for the AI Representative |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds ownership context but lacks details on rep capabilities, limitations, or response format.
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?
A single, direct sentence with no superfluous words, effectively conveying the 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?
The tool is simple with one parameter and annotations, but the description could hint at the nature of the AI response or expected behavior, especially given no output schema.
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?
The schema covers the 'question' parameter with a description; the tool description adds no additional meaning beyond 'Question for the AI Representative'. Baseline 3 as schema coverage is 100%.
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 uses a specific verb ('Ask') and resource ('the authenticated user's own PingRep AI Representative'), clearly distinguishing from siblings like 'ask_contact_ai_rep' and 'ask_ai_rep'.
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 use for the user's own representative, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft a message to a saved contact. This does not send anything.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message text | |
| contactId | Yes | Saved contact ID from list_my_contacts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only (readOnlyHint=false), which aligns with drafting. The description adds the key behavioral point that no message is sent. However, it does not disclose what happens after drafting—whether the draft is saved, returned, or discarded—leaving ambiguity about side effects. More transparency about the output or storage would improve this.
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?
Two sentences with no redundant words. The first sentence states the action, the second clarifies a critical constraint. Information is front-loaded and every part contributes to understanding the tool.
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?
With no output schema, the description fails to explain what the tool returns (e.g., draft ID, confirmation). For a common task like drafting, this omission reduces completeness. The description covers purpose and distinction but lacks result details. Considering the tool's simplicity, a 3 is reasonable.
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 does not add new meaning beyond the schema; 'contactId' is described as 'Saved contact ID from list_my_contacts' in both places, and 'message' as 'Message text'. Baseline score of 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 action: 'Draft a message to a saved contact'. The verb 'draft' is specific and distinct from siblings like 'send_message_to_contact'. The additional sentence 'This does not send anything' reinforces the tool's purpose and differentiates it from send tools.
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 this tool by stating 'does not send anything', suggesting it is for composing a message without sending. However, it does not explicitly mention alternatives or prerequisites like having a contact from list_my_contacts. The contrast with send_message_to_contact is clear but not named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for one saved contact owned by the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | Saved contact ID from list_my_contacts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds the important constraint that the contact must be owned by the authenticated user, which is critical for access control and not evident from annotations alone.
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?
One sentence with no extraneous information. The key details (verb, resource, ownership) are front-loaded. Every word earns its place.
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 read operation with one required parameter and no output schema, the description is largely adequate. However, it could be improved by hinting at what 'details' includes (e.g., fields returned) or confirming that the response contains the full contact object.
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% (contactId has a description with format and source). The description reinforces that the contact is 'saved' and 'owned', but does not add new meaning beyond the schema. 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 specifies the verb 'Get details', the resource 'one saved contact', and the ownership constraint 'owned by the authenticated user'. This distinguishes it from sibling tools like list_my_contacts (list vs. single) and save_contact (save vs. get).
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 the tool (to fetch details of a specific saved contact) but does not provide explicit guidance on when not to use it or how to choose between this and sibling tools like get_my_profile or ask_ai_rep. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the authenticated PingRep user's own AI Representative profile.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. Description adds no behavioral context beyond what's already declared. No mention of auth or other traits.
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?
Single sentence, concise, and front-loaded with essential information.
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 zero-param read-only tool with annotations, the description is sufficient. No output schema but return type is implied.
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, so schema coverage is 100%. Description doesn't need to add parameter info. Baseline 4 for zero-param tools.
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 action 'Get', resource 'AI Representative profile', and scope 'authenticated PingRep user's own'. Distinguishes from siblings like 'get_profile' and 'search_profiles'.
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?
No explicit when-to-use or alternatives, but the purpose is simple and self-explanatory. Implied usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a PingRep professional profile by ID or username slug. Returns the person's name, title, company, bio, skills, work experience, education, and social links.
| Name | Required | Description | Default |
|---|---|---|---|
| profileId | Yes | The profile identifier — either a UUID or a username slug (e.g. 'marcus') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds the return fields but does not contradict. The description does not significantly add behavioral context beyond the 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?
Two concise sentences with no wasted words. The purpose is front-loaded and immediately clear.
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 one parameter, readOnlyHint annotation, and no output schema, the description adequately covers purpose, identifier format, and return fields. Slightly short of complete due to lack of explicit mention of output structure.
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% and describes the parameter. The description mentions 'by ID or username slug', which aligns with the schema. Baseline 3 as description adds minimal extra meaning.
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 verb 'Get', the resource 'PingRep professional profile', and the identification method ('by ID or username slug'). It also lists the returned fields, distinguishing it from sibling tools like 'get_my_profile' and 'get_contact'.
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 usage when needing a profile by ID or slug, but does not explicitly state when not to use it or compare with alternatives like 'get_my_profile' for own profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the authenticated user's PingRep AI Representative analytics summary.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds no further behavioral context beyond the verb 'Get.' 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?
Single sentence, 10 words, no redundancy. Every word is necessary and front-loaded.
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 should hint at what the summary includes (e.g., metrics). It only says 'analytics summary,' which is vague. The tool is simple but the return is not described.
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?
The schema already documents the 'days' parameter with a clear description and default. The tool description does not add meaning beyond the schema, so baseline score of 3 applies.
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 action (Get), the resource (analytics summary), and the owner (authenticated user's PingRep AI Representative). It distinguishes from siblings like get_profile or ask_ai_rep by focusing on analytics.
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?
No guidance on when to use this tool versus alternatives (e.g., ask_ai_rep for interactive queries or get_profile for static data). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated user's saved PingRep contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum contacts to return | |
| offset | No | Number of contacts to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds user scope ('authenticated user's saved contacts') but doesn't disclose pagination behavior or return format beyond schema.
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?
Single sentence with no filler, front-loaded with verb and resource. Every word earns its place.
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 list tool with 2 well-documented parameters and a readOnlyHint annotation, the description is sufficient. It could mention that it returns a list, but the lack of output schema makes it slightly less 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 coverage is 100%; description adds no additional meaning beyond what the schema already provides (limit, offset with descriptions). Baseline 3.
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?
Description clearly states the action: list contacts belonging to the authenticated user. It distinguishes from siblings like get_contact (single) and search_profiles (broader search).
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?
Implies usage for retrieving saved contacts, but no explicit when-to-use vs alternatives like search_profiles or get_contact. No exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save your contact information after interacting with a PingRep AI Representative. This lets the profile owner know you are interested in connecting. Requires name and email at minimum.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Your full name | |
| Yes | Your email address | ||
| notes | No | A short note for the profile owner (optional) | |
| phone | No | Your phone number (optional) | |
| profileId | Yes | The profile identifier (UUID or username slug) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that saving notifies the profile owner, adding behavioral context beyond the openWorldHint annotation. However, it does not detail side effects like permissions or potential conflicts.
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 sentences, front-loaded with action and context, and contains no unnecessary words. It is efficient and easy to parse.
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 omits return value details. It does not cover error handling or conditions like duplicates. While adequate, it leaves gaps for a save operation with 5 parameters.
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 all parameters are described in the schema. The description only adds minimal emphasis on required fields (name, email) but does not provide additional meaning for optional parameters like notes or phone.
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 saves contact information after interacting with a PingRep AI Representative, specifying the action and resource. It distinguishes from sibling tools like list_my_contacts and get_contact by emphasizing the act of saving and connecting.
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 indicates the tool should be used after interacting with a rep and requires name and email. It provides clear context for when to use but does not explicitly exclude scenarios or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the PingRep professional directory to find professionals by role, location, or keyword. Only returns profiles that have opted into AI discoverability. Use this to help users find real estate agents, attorneys, financial advisors, and other professionals.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Professional role to filter by (e.g., 'real-estate-agent', 'attorney', 'financial-advisor') | |
| limit | No | Maximum number of results to return (default: 10) | |
| query | No | Free-text search query matching name, title, or company | |
| location | No | Location to filter by (e.g., 'New York', 'San Francisco') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds that only opt-in profiles are returned, which is a key behavioral constraint. No mention of pagination or rate limits, but sufficient given read-only nature.
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?
Two concise sentences with no wasted words. Front-loaded with action and purpose. 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?
No output schema exists, but the description covers key aspects: what it searches, filters, and constraints. Lacks details on default ordering or result structure, but adequate for a straightforward search 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?
Schema coverage is 100% with clear parameter descriptions. The description does not add extra detail beyond the schema's property descriptions, maintaining baseline.
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 it searches a professional directory with specific filters (role, location, keyword) to find professionals, distinguishing it from siblings like 'list_my_contacts' which likely lists the user's own contacts.
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 usage context: 'Use this to help users find real estate agents, attorneys, financial advisors...' and notes opt-in constraint, but does not contrast with sibling tools like 'get_profile' or 'list_my_contacts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to a saved contact only after explicit user confirmation. Set confirmSend to true only after the user approves the exact message.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message text | |
| contactId | Yes | Saved contact ID from list_my_contacts | |
| confirmSend | Yes | Must be true after explicit confirmation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, and the description adds safety guidance: the confirmSend parameter must be true only after explicit user approval. This goes beyond annotations by detailing the required user confirmation workflow.
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 sentences, front-loads the core action and condition, and contains no unnecessary words or redundancy.
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 lacks information about return values or error handling; given no output schema, this is a gap. It covers the safety aspect adequately but not the full behavioral context of a send operation.
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 adds practical usage context for confirmSend ('set to true only after user approves'), which reinforces the intended workflow beyond the schema description.
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: sending a message to a saved contact after explicit user confirmation. It distinguishes from siblings like draft_message_to_contact (which drafts without sending) by emphasizing the confirmation requirement.
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 on when to use this tool (only after user approval) but does not explicitly mention alternatives like draft_message_to_contact for the drafting phase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0ask_ai_repask_contact_ai_repask_my_ai_repdraft_message_to_contactget_contactget_my_profileget_profileget_rep_analytics_summarylist_my_contactssave_contactsearch_profilessend_message_to_contactMost tools have distinct purposes, but the three 'ask' tools (ask_my_ai_rep, ask_contact_ai_rep, ask_ai_rep) could cause confusion, as could get_contact vs. get_profile without careful reading.
All tools follow a consistent verb_noun pattern with snake_case (e.g., list_my_contacts, get_profile, search_profiles). Naming is predictable and uniform.
With 12 tools, the server is well-scoped for a professional networking and AI representative service. It covers contacts, profiles, messaging, AI queries, analytics, and search without being bloated.
The tool surface covers core workflows but has notable gaps: missing update and delete for contacts, no message history listing, and limited AI rep management. CRUD is incomplete for contacts.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI agents to 1000+ apps with managed authentication and tool-calling.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Connect AI clients to biomedical data and tools.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pingrep/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
