Refgrow MCP Server

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Each tool targets a specific resource (affiliate, conversion, coupon, referral) and action (create, delete, get, list, update), making it easy for an agent to select the correct one. For example, create_affiliate and update_affiliate are clearly differentiated by their actions on the same resource.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_affiliate, list_conversions, and update_coupon. All tools use snake_case with clear verbs (create, delete, get, list, update) and nouns (affiliate, conversion, coupon, referral), making the set predictable and readable.
Tool Count5/5
With 18 tools, the count is well-scoped for an affiliate management domain, covering CRUD operations for four core resources (affiliate, conversion, coupon, referral). Each tool earns its place by providing necessary functionality without redundancy, such as detailed get operations alongside list views.
Completeness5/5
The tool surface offers complete CRUD/lifecycle coverage for the affiliate management domain, with no obvious gaps. All four resources have create, get, list, update, and delete operations (except referrals, which lack update and delete, but this is reasonable as referrals are typically immutable records). This ensures agents can handle full workflows without dead ends.
Average 3.2/5 across 18 of 18 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 provided, the description carries the full burden of behavioral disclosure. It mentions that an affiliate 'receives a unique referral code' and 'can start referring customers', which adds some context about outcomes, but fails to address critical aspects like required permissions, error conditions, or what the response contains (e.g., success confirmation, affiliate ID).
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 concise and front-loaded, consisting of two clear sentences that directly state the tool's purpose and key outcomes. There is no wasted language, and every sentence contributes essential information efficiently.
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?
Given the complexity of a creation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., idempotency, error handling), return values, and usage context, which are crucial for an agent to invoke the tool correctly in a real-world scenario.
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%, so the schema fully documents parameters. The description does not add any semantic details beyond the schema, such as explaining the significance of 'partner_slug' or constraints on 'referral_code'. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 verb 'create' and resource 'affiliate' with the context 'in your Refgrow project', making the purpose evident. It distinguishes from siblings like 'update_affiliate' or 'delete_affiliate' by specifying creation, but does not explicitly differentiate from other creation tools (e.g., 'create_conversion').
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 prerequisites, conditions for use, or comparisons with sibling tools like 'create_conversion' or 'create_coupon', 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 carries full burden but only states it 'manually create[s]' a record without disclosing behavioral traits like required permissions, whether it's idempotent, what happens on duplicate emails, or error handling. It lacks details on side effects, rate limits, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('manually create a referred user record') and adds optional context ('optionally linking them to a specific affiliate') without any wasted words. It's appropriately sized for the tool's complexity.
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?
For a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'referred user record' entails, what happens after creation, or how this interacts with other referral-related tools. Given the complexity of manual creation in an affiliate system, more context is needed.
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%, so the schema fully documents parameters. The description adds no additional meaning beyond implying optional linking to an affiliate, which is already covered in the schema's 'affiliate_id' parameter. Baseline 3 is appropriate as the schema handles parameter documentation.
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 ('manually create') and resource ('referred user record'), with the optional linking to an affiliate providing additional specificity. It distinguishes from siblings like 'create_affiliate' or 'create_conversion' by focusing on referrals, though it doesn't explicitly contrast with them.
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 like 'create_conversion' or 'list_referrals'. The description mentions optional linking to an affiliate but doesn't explain prerequisites, constraints, or typical use cases for manual creation versus automated processes.
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 burden. It states the tool deletes a record, implying a destructive mutation, but lacks critical behavioral details such as whether deletion is permanent, requires specific permissions, has side effects (e.g., cascading deletions), or returns confirmation. 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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.
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?
Given the tool's complexity (a destructive operation with no annotations and no output schema), the description is incomplete. It fails to address behavioral aspects like deletion consequences, error handling, or return values, leaving the agent with insufficient context for safe and effective use.
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%, with the single parameter 'id' documented as 'Conversion ID to delete'. The description adds no additional meaning beyond this, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating value.
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 ('Delete') and the resource ('a conversion record by its ID'), making the purpose immediately understandable. It distinguishes from siblings like 'delete_affiliate' or 'delete_coupon' by specifying the resource type, though it doesn't explicitly contrast with other deletion tools.
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 doesn't mention prerequisites (e.g., needing an existing conversion ID), exclusions, or comparisons with related tools like 'update_conversion' or 'get_conversion', leaving the agent to infer usage context.
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 implies a read-only operation ('Get') but doesn't confirm safety aspects like whether it's idempotent, requires specific permissions, or has rate limits. It mentions the data returned but not the format or potential errors, leaving gaps in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes key details. It avoids redundancy and wastes no words, though it could be slightly more structured by separating usage guidelines from the purpose for clarity.
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 tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers what data is retrieved but lacks information on return format, error handling, or dependencies on other tools. For a simple read operation, this is minimally viable but leaves room for improvement.
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 description adds minimal value beyond the input schema, which has 100% coverage. It specifies that the email parameter is used to identify 'a specific affiliate,' but the schema already describes it as 'The affiliate's email address.' No additional semantics like format hints or usage examples are provided, aligning with the baseline score for high schema coverage.
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's purpose: 'Get detailed information about a specific affiliate by their email address, including click count, signups, purchases, and earnings.' It specifies the verb ('Get'), resource ('affiliate'), and key details retrieved. However, it doesn't explicitly distinguish this from sibling tools like 'list_affiliates' or 'get_referral_details', which would require 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'get_affiliate_details' over 'list_affiliates' for bulk data or 'get_referral_details' for related information, nor does it specify prerequisites like authentication or rate limits. This lack of contextual guidance limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation ('Get details'), but doesn't disclose permissions, error handling, rate limits, or response format. For a tool with zero annotation coverage, this is inadequate transparency.
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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple lookup tool and front-loads the core purpose effectively.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' include, error conditions, or behavioral traits like idempotency. For a tool with no structured metadata, the description should provide more context to compensate.
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 description coverage is 100%, with the single parameter 'id' documented as 'Conversion ID'. The description adds no additional meaning beyond this, such as ID format or sourcing. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 details') and resource ('specific conversion by its ID'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_conversions' or 'get_affiliate_details', which would require mentioning it retrieves individual records rather than collections.
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 doesn't mention siblings like 'list_conversions' for browsing multiple conversions or 'get_affiliate_details' for related data, leaving the agent to infer usage from naming conventions alone.
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 full burden but offers minimal behavioral insight. It implies a read operation ('Get details') but doesn't disclose permissions, rate limits, error handling, or return format. This leaves significant gaps for a tool that likely interacts with sensitive data.
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, efficient sentence with zero wasted words. It's front-loaded with the core purpose ('Get details for a specific coupon'), making it immediately clear and appropriately sized for a simple tool.
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?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks context on what 'details' include, error scenarios (e.g., invalid ID), or behavioral traits like idempotency, leaving the agent with insufficient information for reliable use.
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%, so the schema already documents the 'id' parameter as an integer. The description adds no additional meaning beyond implying it retrieves details for that ID, aligning with the baseline for high schema coverage.
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 details') and resource ('a specific coupon by its ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_coupons' or 'get_affiliate_details' beyond the resource name, missing explicit sibling distinction.
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 doesn't mention prerequisites (e.g., needing a coupon ID), contrast with 'list_coupons' for browsing, or specify use cases like retrieving details for a known coupon.
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 of behavioral disclosure. While 'Get details' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what details are returned (e.g., user status, referral history). This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned (e.g., user attributes, referral metrics) or potential behavioral aspects like error handling. For a tool that likely returns structured data about referrals, this leaves the agent with insufficient context.
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%, so the input schema fully documents the 'email' parameter. The description adds no additional meaning beyond what's in the schema (e.g., format constraints or examples), resulting in the baseline score of 3 where the schema does the heavy lifting.
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 verb ('Get details') and resource ('for a specific referred user'), specifying retrieval of information about a referred user. However, it doesn't explicitly differentiate from sibling tools like 'get_affiliate_details' or 'list_referrals' beyond the email parameter focus, which keeps it from a perfect score.
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 like 'list_referrals' or 'get_affiliate_details', nor does it mention prerequisites or exclusions. It merely states the basic function without contextual usage advice.
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 burden. It states this is an update operation, implying mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, error handling (e.g., if affiliate not found), or rate limits. The description adds minimal context beyond the basic action.
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, efficient sentence that front-loads the core action ('update an existing affiliate's details') and enumerates key fields without unnecessary elaboration. Every word contributes to understanding the tool's purpose, making it appropriately sized and well-structured.
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?
Given no annotations and no output schema, the description is incomplete for a mutation tool with 5 parameters. It lacks details on behavioral aspects (e.g., side effects, error responses), output format, or dependencies. While concise, it doesn't compensate for the missing structured information, leaving gaps in understanding how the tool behaves in practice.
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%, with all parameters well-documented in the schema (e.g., 'email' as current email, 'new_email' as new address). The description lists updatable fields (email, referral code, status, partner slug), which aligns with schema parameters but doesn't add significant meaning beyond what's already in the structured data. Baseline 3 is appropriate given high schema coverage.
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 verb ('update') and resource ('existing affiliate's details'), specifying what fields can be modified (email, referral code, status, partner slug). It distinguishes from siblings like 'create_affiliate' by focusing on updates rather than creation, though it doesn't explicitly contrast with 'update_conversion' or 'update_coupon' which operate on different resources.
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 doesn't mention prerequisites (e.g., affiliate must exist), exclusions (e.g., cannot update non-existent affiliates), or comparisons with siblings like 'delete_affiliate' or 'get_affiliate_details'. Usage is implied only by the verb 'update'.
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 of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, error handling, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that front-loads the purpose and enumerates updatable fields without unnecessary words. Every part earns its place, making it highly concise and well-structured for quick comprehension.
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?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, authentication needs), response format, and usage context. For a 6-parameter update operation, more contextual information is needed to guide effective use.
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%, so the schema already documents all parameters thoroughly. The description lists the updatable fields (code, linked affiliate, payment provider IDs, status), which aligns with the schema but doesn't add meaningful semantics beyond what's provided in the structured data. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Update') and resource ('existing coupon') with specific fields that can be modified (code, linked affiliate, payment provider IDs, status). It distinguishes from siblings like 'create_coupon' by specifying 'existing coupon,' but doesn't explicitly differentiate from other update tools like 'update_affiliate' or 'update_conversion' beyond the resource type.
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 doesn't mention prerequisites (e.g., needing an existing coupon ID), exclusions, or comparisons with siblings like 'get_coupon' for retrieval or 'delete_coupon' for removal. Usage is implied by the action but not explicitly defined.
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. While 'update' implies mutation, it doesn't specify required permissions, whether changes are reversible, error handling, or what the response looks like. The description adds minimal context beyond the basic 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 efficiently structured in two sentences: the first states the core purpose, and the second provides practical examples. Every word earns its place with zero waste, making it easy to parse.
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 mutation nature of the tool, 8 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, error cases, or output format, leaving gaps for an AI agent to infer.
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%, so the schema already documents all 8 parameters thoroughly. The description mentions 'value' and 'paid' as common updates, which aligns with the schema but doesn't add significant meaning beyond it. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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 ('update') and resource ('conversion's details'), and provides specific examples of common updates ('mark as paid or update its value'). However, it doesn't explicitly differentiate this tool from sibling tools like 'update_affiliate' or 'update_coupon' beyond the resource name.
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 like 'create_conversion' or 'get_conversion', nor does it mention prerequisites or exclusions. The phrase 'commonly used' hints at typical scenarios but doesn't offer explicit usage rules.
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 mentions 'Manually create' and commission calculation behavior, which adds some context beyond basic creation. However, it fails to disclose critical behavioral traits: whether this is a mutating operation (implied but not stated), permission requirements, idempotency, error handling, or what happens on success (e.g., returns a conversion ID). For a creation tool with 11 parameters, this is inadequate.
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 appropriately concise with two sentences that cover the core purpose and key usage notes. It's front-loaded with the main action. However, the second sentence could be slightly more structured to separate affiliate identification from commission logic, but overall it avoids waste.
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 complexity (11 parameters, creation operation) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose and hints at some behaviors but misses important context: no output information, no error scenarios, and incomplete behavioral transparency. It relies heavily on the well-documented schema, leaving gaps for agent 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it clarifies that 'value' is auto-calculated for purchases if omitted, and that 'affiliate_id' or 'referral_code' can identify affiliates. This provides some high-level context but doesn't significantly enhance parameter understanding beyond the schema's detailed descriptions.
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's purpose: 'Manually create a conversion (signup or purchase).' It specifies the verb ('create') and resource ('conversion') with subtypes. However, it doesn't explicitly differentiate from sibling tools like 'create_affiliate' or 'create_coupon' beyond the resource type, missing an opportunity to clarify domain boundaries.
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 provides implied usage guidance by mentioning 'For purchases, the commission is auto-calculated from project settings if value is not provided' and 'You can identify the affiliate by ID or referral code.' This suggests when to omit certain parameters. However, it lacks explicit when-to-use vs. alternatives (e.g., compared to 'update_conversion' or automated conversion tracking), and no prerequisites or exclusions are stated.
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 mentions filtering and searching capabilities but fails to describe critical behaviors such as pagination handling (implied by limit/offset in schema but not explained), return format, error conditions, or rate limits. For a list operation with 5 parameters, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that front-loads the core purpose and briefly mentions filtering options. There is no wasted language, and it's appropriately sized for the tool's complexity, making it easy to parse quickly.
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?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description is insufficient. It lacks details on behavioral traits like pagination, return format, or error handling, and doesn't compensate for the absence of annotations or output schema. This leaves the agent with incomplete context for effective tool 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning filtering by status, affiliate, or coupon code search, which aligns with the schema but doesn't provide additional semantic context beyond what's in the parameter descriptions. This meets the baseline for high schema coverage.
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 coupon codes') and resource ('associated with affiliates in your project'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_coupon' or 'list_affiliates' beyond mentioning affiliates as a filter option, which keeps it from a perfect score.
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 usage by mentioning filtering options ('Filter by status, affiliate, or coupon code search'), suggesting when to use it for filtered queries. However, it lacks explicit guidance on when to choose this over alternatives like 'get_coupon' or 'list_affiliates', and doesn't specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 that deletion 'also removes their associated referral data', which adds valuable context about side effects. However, it lacks details on permissions, reversibility, or error handling, leaving gaps 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 two concise sentences that are front-loaded with the primary action and include important side-effect information. Every word earns its place without redundancy or fluff.
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?
For a destructive mutation tool with no annotations and no output schema, the description is minimally adequate. It covers the main action and a key side effect, but lacks details on permissions, response format, or error conditions that would be helpful for an 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 has 100% description coverage, with the 'email' parameter clearly documented. The description doesn't add any additional meaning beyond what the schema provides, such as format examples or edge cases, so it meets the baseline for high schema coverage.
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 ('Delete') and resource ('an affiliate from your project'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_conversion' or 'delete_coupon', which prevents a perfect score.
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 doesn't mention prerequisites, consequences, or compare it to sibling tools like 'update_affiliate' or 'list_affiliates', leaving usage context unclear.
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 full burden but only mentions creation and optional attribution features. It lacks critical behavioral details: whether this requires specific permissions, if it's idempotent, what happens on duplicate coupon codes, rate limits, or what the response contains. For a creation tool with zero annotation coverage, this is insufficient.
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?
Two concise sentences that efficiently convey the core purpose and key optional features. No redundant information or unnecessary elaboration, making it easy to parse and understand quickly.
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?
For a creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after creation (e.g., success response, error conditions), permissions needed, or system behavior with duplicate codes. The schema handles parameters well, but behavioral context is lacking.
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%, providing good documentation for all parameters. The description adds minimal value beyond the schema, mentioning 'optionally tie it to a Stripe coupon ID or LemonSqueezy discount code' which corresponds to two parameters but doesn't provide additional context about their usage or interactions.
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 specific action ('Create a new coupon code') and resource ('linked to an affiliate'), with additional details about optional Stripe/LemonSqueezy integration. It distinguishes from sibling tools like 'update_coupon' or 'delete_coupon' by specifying creation rather than modification or deletion.
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 usage when creating coupons for affiliates, particularly with optional payment system integrations, but doesn't explicitly state when to use this versus alternatives like 'update_coupon' or when not to use it (e.g., for existing coupons). No prerequisites or exclusions 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what the tool does (listing with filtering) but doesn't mention important behavioral aspects like whether this is a read-only operation, pagination behavior beyond the offset parameter, rate limits, authentication requirements, or what the output format looks like. The description is functional but lacks 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences that convey the core purpose and key capabilities. The first sentence establishes the main function, and the second adds important filtering context. There's no wasted verbiage, though it could be slightly more front-loaded with the most critical information.
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?
For a list tool with 4 parameters and no output schema, the description provides adequate functional context but lacks operational completeness. It explains what the tool does and filtering options, but doesn't address output format, pagination behavior, or error conditions. With no annotations and no output schema, users must infer these aspects from the parameter names alone.
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%, so the schema already fully documents all 4 parameters. The description mentions filtering by 'affiliate or conversion status' which aligns with the schema's affiliate_id and status parameters, but adds no additional semantic context beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
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 verb ('List') and resource ('referred users'), specifies they are 'signups tracked through affiliate links', and distinguishes from siblings by focusing on referral relationships rather than affiliates, conversions, or coupons directly. It explicitly mentions showing 'which affiliate referred each user', which differentiates it from tools like list_affiliates or list_conversions.
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 usage context by mentioning filtering capabilities ('Filter by affiliate or conversion status'), but doesn't explicitly state when to use this tool versus alternatives like get_referral_details or list_conversions. It provides some guidance through the filtering mention but lacks explicit comparisons or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool lists data with stats and supports filtering/pagination, which are useful behavioral traits. However, it doesn't mention authentication requirements, rate limits, potential side effects, or response format details, leaving gaps for a tool with no annotation coverage.
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, well-structured sentence that efficiently conveys purpose, scope (stats included), and key features (filtering, pagination) without unnecessary words. It's front-loaded with the main action and appropriately sized for its informational content.
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 no annotations and no output schema, the description provides basic purpose and features but lacks details on authentication, error handling, response structure, or deeper behavioral context. It's adequate for a read-only list tool but incomplete for full agent understanding without structured support.
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%, so the schema fully documents all three parameters (status, limit, offset) with descriptions, enums, and constraints. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for high schema coverage.
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 verb ('List') and resource ('all affiliates in your Refgrow project') with specific stats included (clicks, signups, purchases, earnings). It distinguishes from siblings like 'get_affiliate_details' by indicating it lists multiple affiliates rather than getting details of one, though it doesn't explicitly contrast with other list tools like 'list_conversions'.
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 usage for retrieving affiliate data with stats and filtering/pagination capabilities, but provides no explicit guidance on when to use this tool versus alternatives like 'get_affiliate_details' for single affiliates or other list tools for different resources. It mentions filtering by status and pagination, which suggests context but lacks explicit when/when-not instructions.
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 of behavioral disclosure. It mentions filtering capabilities but lacks details on permissions required, rate limits, pagination behavior (beyond schema parameters), or what the output looks like (e.g., format, fields). For a read operation with 7 parameters and no annotations, this is insufficient.
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, efficient sentence that front-loads the purpose and lists key filters without unnecessary words. Every part of the sentence contributes to understanding the tool's functionality, making it appropriately sized and well-structured.
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 complexity (7 parameters, no annotations, no output schema), the description is adequate but has clear gaps. It covers the purpose and basic filters but lacks behavioral context (e.g., permissions, output format) and does not fully compensate for the absence of annotations and output schema, making it minimally viable.
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%, so the schema already documents all parameters thoroughly. The description adds minimal value by listing filterable attributes (type, affiliate, date range, paid status) but does not provide additional syntax or format details beyond what the schema specifies, meeting the baseline for high coverage.
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 verb ('List') and resource ('conversions (signups and purchases) tracked in your affiliate program'), specifying what the tool does. It distinguishes itself from siblings like 'get_conversion' (singular) by indicating it lists multiple conversions with filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by listing filterable attributes (type, affiliate, date range, paid status), which helps an agent understand when to apply this tool. However, it does not explicitly state when not to use it or name alternatives, such as 'get_conversion' for a single conversion, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 adds valuable context beyond the basic delete action by mentioning the Stripe integration effect ('If linked to a Stripe coupon, it will also be deleted from Stripe'), which is crucial for understanding side effects. However, it does not cover other behavioral aspects like permissions, error handling, or confirmation prompts.
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 appropriately sized and front-loaded, consisting of two concise sentences that directly convey the core action and a critical side effect. There is no wasted language, and every sentence earns its place by adding essential information.
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?
Given the tool's complexity (a destructive operation with external integration), no annotations, and no output schema, the description is reasonably complete. It covers the primary action and a key behavioral trait (Stripe deletion), but it could be more comprehensive by addressing potential errors, return values, or security considerations.
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, with the 'id' parameter fully documented. The description does not add any additional meaning or details beyond what the schema provides (e.g., format constraints or examples). According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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 specific action ('Delete') and resource ('a coupon by its ID'), distinguishing it from sibling tools like 'get_coupon' or 'update_coupon'. It precisely defines what the tool does without being vague or tautological.
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 usage by specifying deletion by ID, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., when not to delete, prerequisites, or comparisons with other deletion tools like 'delete_affiliate'). It lacks clear exclusions or context for selection.
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:

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

Score Badge

Copy to your README.md:

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

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/refgrow/refgrow-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server