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., "@Feather MCP Server search for leads about marketing in groups"
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.
Connect AI agents to Facebook lead generation and CRM automation.
An MCP (Model Context Protocol) server that exposes Feather Connector and Feather Messenger CRM tools to any AI agent. Search leads, manage contacts, send broadcasts, and track growth metrics through a universal plugin interface.
Zero-install via npx:
npx feather-mcp-serverOr install and build locally:
npm install
npm run build
node dist/index.jsTest with the MCP Inspector:
npx @modelcontextprotocol/inspector node dist/index.jsRelated MCP server: Facebook MCP Server
Try all 10 tools without installing the Chrome extension!
The server runs in demo mode by default, returning realistic mock data (leads, contacts, stats, growth metrics) so you can explore every tool immediately. Set
FEATHER_DEMO=falsewhen you're ready to connect to the live Feather extensions.
Variable | Default | Description |
|
| Use mock data ( |
Claude Desktop — add to claude_desktop_config.json
Cursor — add as an MCP server in settings
VS Code — via MCP extension
Windsurf — add as an MCP server
OpenClaw — add to your OpenClaw config
Any MCP client — standard stdio transport
Tool | Description |
| Search for potential leads by keywords, groups, or interests |
| Send a friend request with an optional note |
| Check status of sent friend requests (pending/accepted/declined) |
| Get overall statistics: sent, accepted, declined, accept rate |
Tool | Description |
| List CRM contacts with optional label, tag, or search filters |
| Add a label to a contact |
| Add a tag to a contact |
| Send a broadcast message to all contacts with a given label |
| Get aggregate CRM stats: contact count, label distribution, recent activity |
Tool | Description |
| Get growth metrics (connections, messages, engagement) over 7d/30d/90d |
{
"tool": "search_leads",
"arguments": {
"query": "marketing",
"limit": 5,
"source": "groups"
}
}{
"tool": "send_broadcast",
"arguments": {
"label": "warm",
"message": "New webinar this Thursday! Link in bio.",
"dryRun": true
}
}{
"tool": "get_growth_metrics",
"arguments": {
"metric": "connections",
"period": "30d"
}
}Add to claude_desktop_config.json:
{
"mcpServers": {
"feather": {
"command": "npx",
"args": ["-y", "feather-mcp-server"]
}
}
}Add to your OpenClaw config:
mcp:
servers:
feather:
command: npx
args:
- -y
- feather-mcp-serversrc/
index.ts Entry point (stdio transport)
server.ts MCP server setup + tool registration
types.ts TypeScript types
utils.ts Helpers (demo mode check, JSON results, error handling)
tools/
connector.ts Feather Connector tools (4 tools)
messenger.ts Feather Messenger CRM tools (5 tools)
analytics.ts Analytics tools (1 tool)
mock/
data.ts Realistic demo data (leads, contacts, stats, growth series)TypeScript + Node.js
@modelcontextprotocol/sdk (official MCP SDK)
zod for input validation
stdio transport (MCP standard)
MIT
Add a label to a Feather CRM contact.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Label to apply | |
| contactId | Yes | Contact identifier |
| Name | Required | Description |
|---|---|---|
| success | Yes | Whether the label was added |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention side effects, idempotency, permissions, or whether existing labels are replaced. This is a significant gap for a mutation tool.
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 a single, concise sentence that immediately communicates the tool's purpose. Every word earns its place, and the structure is 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?
The tool is simple, and the schema covers parameters. However, the absence of annotations and usage guidance leaves gaps in behavioral and contextual understanding. An output schema exists, so return values do not need to be explained, but more behavioral context 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?
The input schema has 100% parameter description coverage (contactId and label are both described). The tool description adds no extra detail beyond the schema, so the baseline 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: 'Add a label to a Feather CRM contact.' It uses a specific verb and resource, making the purpose obvious. However, it does not differentiate from the sibling tool 'add_tag', which could be seen as a closely related alternative, so it falls short of a 5.
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 is provided on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or context. The description merely states the action without explaining the appropriate usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a tag to a Feather CRM contact.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag to apply | |
| contactId | Yes | Contact identifier |
| Name | Required | Description |
|---|---|---|
| success | Yes | Whether the tag was added |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the core action ('add a tag') with no additional behavioral details such as whether the operation is idempotent, what happens if the tag already exists, or whether permissions are required. The description is not misleading but is minimal.
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 a single clear sentence with no extraneous information. It is appropriately concise for a simple tool with two parameters.
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, has full schema coverage, and includes an output schema, reducing the burden on the description. However, the description does not address usage context or potential behavioral nuances. It is adequate for a basic add-tag operation but lacks any additional context that could help an agent decide when to use it.
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%: both 'contactId' and 'tag' have descriptions in the schema. The tool description adds little beyond the schema, merely restating the action and adding the 'Feather CRM' context. The schema already fully documents each parameter, so the baseline 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 'Add a tag to a Feather CRM contact' clearly states the action (add), the object (tag), and the target (contact). It is specific and uses a verb-noun structure. However, it does not explicitly differentiate itself from the sibling tool 'add_label', which may perform a similar operation on labels rather than tags.
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 alternatives. It does not mention any prerequisites, exclusions, or context where this tool is preferred. The sibling 'add_label' suggests a possible alternative for label operations, but no guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get overall Feather Connector statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Time window for aggregating stats |
| Name | Required | Description |
|---|---|---|
| sent | Yes | Total requests sent |
| accepted | Yes | Total requests accepted |
| declined | Yes | Total requests declined |
| acceptRate | Yes | Acceptance rate percentage |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must convey behavioral traits. The phrase 'Get overall statistics' implies a read operation but does not state authorization needs, rate limits, aggregation behavior, or whether the 'period' parameter affects the aggregation. This leaves significant behavioral ambiguity.
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 a single, front-loaded sentence with no wasted words. It efficiently states the action, though it could have included more context without harming 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?
While the schema is simple (one optional parameter) and there is an output schema, the description fails to define what 'Feather Connector' refers to or to distinguish this from sibling stats tools. Given the existence of get_crm_stats and get_growth_metrics, the description is incomplete for an agent to know when to invoke 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?
The input schema already fully documents the single 'period' parameter with a description and enum values, achieving 100% schema coverage. The tool description adds no additional meaning beyond the schema, so the 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 uses a specific verb ('Get') and a clear resource ('Feather Connector statistics'), making the tool's basic action apparent. However, it does not differentiate this from sibling tools like get_crm_stats or get_growth_metrics, both of which are also statistics tools, leaving ambiguity about what 'Connector' specifically covers.
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?
There is no guidance on when to use this tool versus alternatives such as get_crm_stats or get_growth_metrics. The description does not provide context for selecting this tool over the sibling statistics tools, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate Feather CRM statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| labels | Yes | Label counts |
| totalContacts | Yes | Total contacts |
| recentActivity | Yes | Recent CRM activity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'Get aggregate statistics' without explicitly stating that it's a read-only operation, nor disclosing any additional behavioral details such as data freshness, permissions, or limitations. The 'Get' verb implies read-only, but this is not made transparent.
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 a single, front-loaded sentence that directly states the action and resource. It contains no fluff or unnecessary words, making it exceptionally 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?
The output schema exists and presumably defines the return structure, so the description need not explain return values. However, the description does not specify what categories of CRM statistics are included or when it should be used over sibling tools. For a simple read-only tool, it is minimally adequate but would benefit from a bit more detail.
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 tool has zero parameters, and the input schema fully covers the (empty) input. The description adds no parameter-level details, but none are needed. The baseline of 4 for zero-parameter tools 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') and the resource ('aggregate Feather CRM statistics'), providing a specific verb and scope. However, it does not explicitly differentiate from sibling tools like get_connector_stats or get_growth_metrics, relying on the CRM qualifier to do so.
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?
There is no guidance on when to use this tool versus the sibling stats tools. The description states only what the tool does, with no context about selecting it for CRM aggregates specifically, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get growth metrics over time.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | Yes | Growth metric to retrieve | |
| period | Yes | Time period for the metric |
| Name | Required | Description |
|---|---|---|
| trend | Yes | Overall trend for the period |
| dataPoints | Yes | Metric data points |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. 'Get growth metrics over time' only states the action and resource, but does not mention read-only nature explicitly, authorization requirements, rate limits, or any nuances of the returned data beyond the output schema. This leaves the agent without important safety or context details, though 'get' implies a read.
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 just six words, 'Get growth metrics over time,' which is extremely concise and front-loaded with the intended action. There is no redundant information, making it an efficient single-sentence summary that 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?
The tool is relatively simple with two enum-based parameters and an output schema, so the description does not need to explain return values. However, it lacks usage context, such as how this differs from sibling metrics tools or what kind of time-series data is returned. The description is adequate for basic invocation but incomplete for a fully informed 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?
The input schema fully documents both parameters (metric and period) with enums and descriptions, resulting in 100% schema coverage. The description adds no additional parameter semantics; it only loosely references 'over time' which maps to the period parameter. Baseline score of 3 is appropriate because the schema carries the parameter 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 'Get growth metrics over time' clearly identifies a read operation for growth metrics with a temporal qualifier. It is specific enough to convey the core function, but does not explicitly differentiate from sibling tools like get_connector_stats or get_crm_stats, which may also retrieve metrics.
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 instead of alternatives, nor any exclusions or prerequisites. Sibling tools such as get_connector_stats and get_crm_stats overlap in purpose, and without clarity on distinguishing use cases, an agent may choose incorrectly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of sent friend requests.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of requests to return | |
| status | No | Filter by friend request status |
| Name | Required | Description |
|---|---|---|
| requests | Yes | Request status list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the operation is a 'check' (implying a read-only action) but does not disclose whether it requires authentication, returns data in any particular order, or how pagination works via the 'limit' parameter. Since it is a minimal statement, it does not provide enough 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 a single concise sentence that directly and clearly conveys the tool's purpose with no redundancy. It is front-loaded and easy to understand.
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 retrieval tool with two optional parameters and an output schema, the description provides a clear purpose. However, it lacks explicit mention of default behavior (e.g., no filters applied when parameters are omitted) or specific use cases, but the schema and output schema fill in most of the details needed for invocation.
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 both parameters ('limit' and 'status') clearly, including their types, ranges, and descriptions, achieving 100% coverage. The description adds no extra semantic information about the parameters; therefore, the baseline 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 tool's function: checking the status of sent friend requests. The verb 'check' + resource 'status of sent friend requests' is specific, and it distinguishes itself from siblings like 'send_friend_request' which handles sending.
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 that this tool is used to retrieve the status of friend requests that were previously sent, which gives some context. However, it does not explicitly state when to use this over alternatives, nor does it mention any prerequisites or situations where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Feather Messenger CRM contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag | |
| label | No | Filter by label | |
| limit | No | Maximum number of contacts to return | |
| search | No | Search by name or tag |
| Name | Required | Description |
|---|---|---|
| total | Yes | Total contacts matching filters |
| contacts | Yes | Contacts list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'List' without elaborating on defaults, pagination limits, whether it returns all contacts or only filtered, or any side effects. This is a significant lack of transparency for a data-retrieval tool.
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 a single sentence and front-loaded, which is concise. However, it is under-specified: it omits critical information about filters and usage context, making it appear minimal rather than appropriately 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?
Despite having an output schema and full parameter coverage, the description lacks essential context such as the tool's filtering options, relationship to sibling tools, or expected behavior. For a tool with 4 optional parameters, the description is too sparse to be considered 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?
The input schema covers 100% of parameters (tag, label, limit, search) with descriptions, so the baseline is 3. The description itself adds no additional parameter semantics; it doesn't mention filtering capabilities or how parameters interact.
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 (list) and resource (Feather Messenger CRM contacts), making the core purpose unambiguous. However, it does not distinguish this tool from siblings like search_leads, which may also list or search contacts, so it lacks sibling differentiation.
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 gives no guidance on when to use this tool versus alternatives. There is no mention of use cases, exclusions, or comparison with sibling tools like search_leads or get_crm_stats, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for potential leads by keywords, groups, or interests.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of leads to return | |
| query | Yes | Search query: keywords, group names, or interests | |
| source | No | Where to search for leads: groups, pages, or general search |
| Name | Required | Description |
|---|---|---|
| leads | Yes | Matching leads |
| totalFound | Yes | Total leads found |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action (search) but does not describe side effects, limitations, or return behavior, leaving the agent without sufficient safety or operational 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 a single concise sentence that is front-loaded with the core action. Every word earns its place, and the structure is easily scannable.
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 covers the core purpose and the schema fully documents parameters, but the lack of usage guidance and behavioral transparency makes it incomplete for an agent to select and invoke confidently. The presence of an output schema reduces the need to explain return values.
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 input schema has 100% description coverage for all three parameters, so the baseline is 3. The description paraphrases the query parameter (keywords, groups, interests) but adds no additional 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 description clearly states the tool searches for potential leads using keywords, groups, or interests. It identifies a specific verb and resource, though it does not explicitly distinguish it from sibling tools like list_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?
No explicit guidance is provided about when to use this tool versus alternatives. The purpose implies it is for finding potential leads, but there are no exclusions or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a broadcast message to labeled contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Label to target | |
| dryRun | No | If true, simulate sending without delivery | |
| message | Yes | Broadcast message body |
| Name | Required | Description |
|---|---|---|
| sent | Yes | Number of messages sent |
| dryRun | Yes | Whether this was a dry run |
| failed | Yes | Number of messages failed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a mutating action (sending) but doesn't disclose side effects, delivery behavior, or the existence of the dryRun parameter. The dryRun simulation behavior is only revealed in the schema, which is insufficient without a description.
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 a single sentence, front-loaded with the action verb 'Send.' It contains no unnecessary words or repetition, making it highly 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?
The tool is straightforward with full schema coverage and an output schema, but the description lacks important contextual information such as when to use it, the effect of dryRun, and any prerequisites. While not critical for a simple send operation, it falls short of being fully self-contained.
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 provides descriptions for all three parameters (label, message, dryRun) with 100% coverage. The tool description adds no additional semantic meaning beyond what the schema states, so it earns the baseline score of 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?
The description clearly states the tool sends a broadcast message to labeled contacts, with a specific verb and resource. It distinguishes from siblings like send_friend_request by specifying labeled contacts as the audience.
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 alternatives such as send_friend_request or list_contacts. No exclusions, prerequisites, or alternative references are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a friend request with an optional note.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional note to include with the request | |
| profileUrl | Yes | Facebook profile URL |
| Name | Required | Description |
|---|---|---|
| success | Yes | Whether the request was accepted |
| requestId | Yes | Request identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states the action and optional note, without covering side effects, permissions, rate limits, or failure modes, which are relevant for a mutating operation.
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 a single, clear sentence with no redundant words. It is well-structured and immediately understood, earning a top score for 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?
Given the simple action and presence of an output schema, the description is minimally adequate, but it omits any context about expected behavior on failure, duplicate requests, or prerequisite conditions. A bit more detail would enhance completeness 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?
The input schema already provides complete descriptions for both parameters (profileUrl and note) with 100% coverage. The description's mention of 'optional note' adds no new information beyond the schema's optionality.
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 ('Send') with a clear resource ('friend request') and mentions the optional note. It is easily distinguished from sibling tools, which focus on leads, contacts, and stats, not friending actions.
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 alternatives, nor does it mention any preconditions or exclusions. It relies solely on the tool name to convey purpose.
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.0add_labeladd_tagget_connector_statsget_crm_statsget_growth_metricsget_request_statuslist_contactssearch_leadssend_broadcastsend_friend_requestThe tools mostly map to distinct actions, but add_label and add_tag have overlapping purposes with similar descriptions. The three stats tools (get_connector_stats, get_crm_stats, get_growth_metrics) could also be confused, though their scopes differ.
All tool names follow a consistent verb_noun pattern using snake_case. Verbs and nouns are clear and predictable, making the toolset easy to navigate.
10 tools is a well-scoped size for a CRM/lead-generation server. Each tool serves a clear function without excessive redundancy.
The core lead-to-broadcast workflow is covered, but there are notable gaps: no way to remove labels/tags, update contacts, or cancel friend requests. This can create dead ends for agents managing contacts.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give AI agents the LinkedIn tools to find, qualify, engage, and follow up with prospects.
Full LinkedIn access for AI agents: leads, messaging, and campaigns with safe limits built in.
AI marketing agent for paid social: Meta ads campaigns, ad creative generation, lead delivery.
60+ Meta Ads tools for AI agents: audits, campaign management, audiences and CAPI tracking.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/auram-stone/feather-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
