Fewsats MCP Server

Official

by Fewsats

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes: balance, billing_info, payment_info, and payment_methods are clearly differentiated for wallet, billing, payment details, and payment methods respectively. However, create_x402_payment_header and pay_offer both involve payment processing and could be slightly confusing, as they target different protocols (X402 vs L402) but share overlapping payment-related functionality.
Naming Consistency4/5
The naming follows a consistent snake_case pattern throughout (e.g., billing_info, payment_methods). However, there is a minor inconsistency with create_x402_payment_header using a more descriptive prefix (create_x402_) while others are simpler nouns or verb_noun combos, slightly deviating from a uniform style.
Tool Count5/5
With 6 tools, the count is well-scoped for a payment and wallet management server. Each tool serves a specific function without redundancy, covering key areas like balance, billing, payments, and payment methods, making it efficient and manageable.
Completeness4/5
The tool set covers core payment and wallet operations well, including balance retrieval, billing info, payment details, payment methods, and payment execution for different protocols. A minor gap exists in lacking tools for updating or deleting payment methods or billing info, but agents can likely work around this with the provided tools.
Average 3.6/5 across 6 of 6 tools scored. Lowest: 3/5.
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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('Retrieve') and includes a conditional action based on status, which adds some context. However, it lacks details on permissions required, error handling, rate limits, or what the return format looks like, leaving significant gaps for a tool that likely interacts with sensitive payment 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 appropriately sized and front-loaded, with the core purpose stated first and additional context provided in a second sentence. Every sentence adds value, and there is no redundant or wasted text, making it efficient and easy to parse.
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 covers the basic purpose and a usage note but misses critical details such as the return format, error conditions, or full behavioral context. For a payment-related tool with no structured metadata, this leaves too much ambiguity for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description does not explain what 'pid' represents (e.g., payment ID, transaction ID) or provide any semantic context beyond the schema. This leaves the parameter meaning unclear, failing to compensate for the low 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 with a specific verb ('Retrieve') and resource ('details of a payment'), making it immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'billing_info' or 'pay_offer', which might also relate to payment information.
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 that if the payment status is 'needs_review', the user should be informed to approve it at app.fewsats.com. This suggests a specific scenario for using the tool, but it doesn't offer explicit guidance on when to use this tool versus alternatives like 'billing_info' or 'create_x402_payment_header', nor does it 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 describes the creation action and the return format, but lacks details on permissions, rate limits, error handling, or whether the operation is idempotent. The example payload adds some context but doesn't fully compensate for the missing behavioral traits.
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 front-loaded with the core purpose, but includes a lengthy JSON example that could be condensed or referenced externally. The sentences are informative but the example takes up substantial space without adding proportional value to 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 no annotations, 2 parameters with 0% schema coverage, no output schema, and nested objects, the description is partially complete. It explains the purpose, parameters, and return value, but lacks details on error cases, side effects, or integration context with sibling tools, leaving gaps for a mutation tool.
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 input schema has 0% description coverage, so the description must compensate. It adds significant meaning by specifying the chain options ('base-sepolia or base') and providing a detailed example structure for 'x402_payload', which clarifies the expected format beyond the schema's generic 'object' type. However, it doesn't explain all possible fields or constraints for the payload.
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 ('Creates a payment header') and the resource ('for the X402 protocol'), which is specific and unambiguous. However, it doesn't explicitly differentiate this tool from its sibling tools like 'pay_offer' or 'payment_info', which might also involve payment-related operations, so it doesn't fully achieve 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 provides no guidance on when to use this tool versus alternatives. It mentions the chain options ('base-sepolia or base') and the payload structure, but doesn't specify prerequisites, when-not-to-use scenarios, or direct comparisons to sibling tools like 'pay_offer' or 'payment_info'.
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 explains the payment process, including the required data structure and what happens if payment status is 'needs_review', which adds useful context. However, it doesn't cover important aspects like authentication requirements, rate limits, error handling, or whether this is a read-only or destructive operation.
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 appropriately sized but not optimally structured. The first sentence clearly states the purpose, but the detailed parameter explanation could be more front-loaded. The JSON structure example is necessary but lengthy, and the final sentence about 'needs_review' status feels somewhat tacked on rather than integrated.
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 (2 parameters with nested objects, no annotations, no output schema), the description provides good parameter semantics but lacks completeness. It doesn't explain the return value format beyond mentioning 'payment status response', and important behavioral aspects like error conditions or side effects are undocumented. The description does the minimum for a payment tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed semantics for the 'l402_offer' parameter, including its complete structure with field descriptions and example values. It also clarifies that 'offer_id' is the identifier to pay, though with less detail than 'l402_offer'. This significantly enhances understanding beyond the bare 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 action ('pays') and target resource ('an offer_id from the l402_offers'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this payment tool from sibling tools like 'create_x402_payment_header' or 'payment_info', which might handle related but different aspects of the payment process.
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 'payment_info' or 'create_x402_payment_header'. The description mentions the tool's function but doesn't specify prerequisites, appropriate contexts, or exclusions, leaving the agent without clear usage direction.
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 this is a retrieval operation (implying read-only) and hints at the return content (billing details), but doesn't cover aspects like authentication needs, rate limits, or error handling. This is adequate but has clear gaps for a tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with three sentences that each add value: stating the purpose, detailing the return, and providing usage context. It's front-loaded with the core function, though the third sentence could be slightly more integrated.
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 simplicity (0 parameters, no output schema, no annotations), the description is reasonably complete for a retrieval operation. However, it lacks details on the return format (e.g., structure of billing details) and doesn't address potential errors or edge cases, which could be helpful for an agent.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score. It could be a 5 if it explicitly noted the lack of parameters, but this is minor.
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 with a specific verb ('Retrieve') and resource ('user's billing information'), making it immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'payment_info' or 'payment_methods', 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 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 that the information can be used as a shipping address for purchases, which suggests when this tool might be relevant. However, it lacks explicit guidance on when to use this versus alternatives like 'payment_info' or 'balance', leaving some ambiguity for the agent.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that Fewsats handles payment method selection automatically, which adds useful context about system behavior. However, it lacks details on permissions, rate limits, error handling, or response format, leaving gaps for a tool that retrieves sensitive financial 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 front-loaded with the core purpose, followed by concise usage guidelines. Every sentence adds value without waste, making it efficient and well-structured for quick comprehension.
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 lack of annotations and output schema, the description provides adequate purpose and usage guidance but falls short on behavioral details like authentication needs, data format, or error cases. For a tool handling payment methods, more context on security or response structure would improve completeness.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on usage context rather than parameters, earning a high score as it avoids redundancy and adds value 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's purpose with a specific verb ('Retrieve') and resource ('user's payment methods'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'payment_info' or 'billing_info', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('rarely need to call this unless instructed by the user, or to troubleshoot payment issues') and when not to use it ('Fewsats will automatically select the best payment method'), effectively distinguishing it from automated processes and clarifying its situational application.
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 effectively describes key behaviors: it's a read operation ('Retrieve'), it accesses user-specific data ('user's wallet'), and it mentions automatic balance management by Fewsats. However, it lacks details on error handling or response format, which could be useful for troubleshooting.
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 highly concise and well-structured, with three sentences that each serve a distinct purpose: stating the tool's function, providing usage guidelines, and explaining automated context. There is no wasted text, and key information is front-loaded for quick comprehension.
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 simplicity (0 parameters, no annotations, no output schema), the description is largely complete. It covers purpose, usage, and behavioral context. However, without an output schema, it doesn't specify what the balance retrieval returns (e.g., currency, format), which could be a minor gap for troubleshooting scenarios.
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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage. A baseline of 4 is applied since no parameters exist, and the description adds value without redundancy.
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 purpose with a specific verb ('Retrieve') and resource ('balance of the user's wallet'), making it immediately understandable. It distinguishes this tool from siblings like 'billing_info' or 'payment_methods' by focusing on wallet balance retrieval rather than payment details or methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines, stating 'You will rarely need to call this unless instructed by the user, or to troubleshoot payment issues.' This clearly indicates when to use the tool (user instruction or troubleshooting) and implies when not to use it (routine operations, as Fewsats handles balance automatically).
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:

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

Score Badge

Copy to your README.md:

[![fewsats-mcp MCP server](https://glama.ai/mcp/servers/Fewsats/fewsats-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Fewsats/fewsats-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/Fewsats/fewsats-mcp'

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