Skip to main content
Glama
Fewsats

Fewsats MCP Server

Official
by Fewsats

pay_offer

Process payments for specific offers using L402 payment protocol data. Submit offer details and payment context to complete transactions through the Fewsats payment system.

Instructions

Pays an offer_id from the l402_offers.

The l402_offer parameter must be a dict with this structure:
{
    'offers': [
        {
            'id': 'test_offer_2',        # String identifier for the offer
            'amount': 1,                 # Numeric cost value
            'currency': 'usd',           # Currency code
            'description': 'Test offer', # Text description
            'title': 'Test Package'      # Title of the package
        }
    ],
    'payment_context_token': '60a8e027-8b8b-4ccf-b2b9-380ed0930283',  # Payment context token
    'payment_request_url': 'https://api.fewsats.com/v0/l402/payment-request',  # Payment URL
    'version': '0.2.2'  # API version
}

Returns payment status response.
If payment status is `needs_review` inform the user he will have to approve it at app.fewsats.com

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offer_idYes
l402_offerYes

Implementation Reference

  • MCP tool handler for 'pay_offer': decorated function that executes the payment by delegating to Fewsats.pay_offer and handles the response. Includes input schema in docstring.
    @mcp.tool()
    async def pay_offer(offer_id: str, l402_offer: dict) -> str:
        """Pays an offer_id from the l402_offers.
    
        The l402_offer parameter must be a dict with this structure:
        {
            'offers': [
                {
                    'id': 'test_offer_2',        # String identifier for the offer
                    'amount': 1,                 # Numeric cost value
                    'currency': 'usd',           # Currency code
                    'description': 'Test offer', # Text description
                    'title': 'Test Package'      # Title of the package
                }
            ],
            'payment_context_token': '60a8e027-8b8b-4ccf-b2b9-380ed0930283',  # Payment context token
            'payment_request_url': 'https://api.fewsats.com/v0/l402/payment-request',  # Payment URL
            'version': '0.2.2'  # API version
        }
    
        Returns payment status response.
        If payment status is `needs_review` inform the user he will have to approve it at app.fewsats.com"""
        return handle_response(Fewsats().pay_offer(offer_id, l402_offer))
  • Registration of the 'pay_offer' tool using the @mcp.tool() decorator.
    @mcp.tool()
  • Input schema and usage description for the l402_offer parameter in the pay_offer tool docstring.
    """Pays an offer_id from the l402_offers.
    
    The l402_offer parameter must be a dict with this structure:
    {
        'offers': [
            {
                'id': 'test_offer_2',        # String identifier for the offer
                'amount': 1,                 # Numeric cost value
                'currency': 'usd',           # Currency code
                'description': 'Test offer', # Text description
                'title': 'Test Package'      # Title of the package
            }
        ],
        'payment_context_token': '60a8e027-8b8b-4ccf-b2b9-380ed0930283',  # Payment context token
        'payment_request_url': 'https://api.fewsats.com/v0/l402/payment-request',  # Payment URL
        'version': '0.2.2'  # API version
    }
    
    Returns payment status response.
    If payment status is `needs_review` inform the user he will have to approve it at app.fewsats.com"""
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.

Install Server

Other Tools

Latest Blog Posts

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