Feather MCP Server

by auram-stone

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
The 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.
Naming Consistency5/5
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.
Tool Count5/5
10 tools is a well-scoped size for a CRM/lead-generation server. Each tool serves a clear function without excessive redundancy.
Completeness3/5
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.
Average 3.2/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![feather-mcp-server MCP server](https://glama.ai/mcp/servers/auram-stone/feather-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/auram-stone/feather-mcp-server)

Score Badge

Copy to your README.md:

[![feather-mcp-server MCP server](https://glama.ai/mcp/servers/auram-stone/feather-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/auram-stone/feather-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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