Skip to main content
Glama
norman-finance

Norman Finance MCP Server

Official

send_invoice_overdue_reminder

Send overdue payment reminders for invoices via email. Configure subject, body, recipient list, and company copy details to streamline collections and improve client communication.

Instructions

Send an overdue payment reminder for an invoice via email.

Args:
    invoice_id: ID of the invoice to send reminder for
    subject: Email subject line
    body: Email body content
    additional_emails: List of additional email addresses to send to
    is_send_to_company: Whether to send the copy to the company email (Owner)
    custom_client_email: Custom email address for the client (By default the email address of the client is used if it is set)
    
Returns:
    Response from the send overdue reminder request

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
additional_emailsNo
bodyYes
custom_client_emailNo
invoice_idYes
is_send_to_companyNo
subjectYes

Implementation Reference

  • The core handler function that implements the send_invoice_overdue_reminder tool logic. It sends an overdue reminder email for a specific invoice using the Norman API.
    @mcp.tool()
    async def send_invoice_overdue_reminder(
        ctx: Context,
        invoice_id: str,
        subject: str,
        body: str,
        additional_emails: Optional[List[str]] = None,
        is_send_to_company: bool = False,
        custom_client_email: Optional[str] = None
    ) -> Dict[str, Any]:
        """
        Send an overdue payment reminder for an invoice via email.
        
        Args:
            invoice_id: ID of the invoice to send reminder for
            subject: Email subject line
            body: Email body content
            additional_emails: List of additional email addresses to send to
            is_send_to_company: Whether to send the copy to the company email (Owner)
            custom_client_email: Custom email address for the client (By default the email address of the client is used if it is set)
            
        Returns:
            Response from the send overdue reminder request
        """
        api = ctx.request_context.lifespan_context["api"]
        company_id = api.company_id
        
        if not company_id:
            return {"error": "No company available. Please authenticate first."}
        
        send_url = urljoin(
            config.api_base_url,
            f"api/v1/companies/{company_id}/invoices/{invoice_id}/send-on-overdue/"
        )
        
        send_data = {
            "subject": subject,
            "body": body,
            "isSendToCompany": is_send_to_company
        }
        
        if additional_emails:
            send_data["additionalEmails"] = additional_emails if additional_emails else []
        if custom_client_email:
            send_data["customClientEmail"] = custom_client_email
            
        return api._make_request("POST", send_url, json_data=send_data)
  • The registration block in the main server setup where register_invoice_tools(server) is called, which in turn registers the send_invoice_overdue_reminder tool along with other invoice tools.
    # Register all tools
    register_client_tools(server)
    register_invoice_tools(server)
    register_tax_tools(server)
    register_transaction_tools(server)
    register_document_tools(server)
    register_company_tools(server)
    register_prompts(server)
    register_resources(server)
  • Import of register_invoice_tools from invoices.py in the main server.py file.
    from norman_mcp.tools.invoices import register_invoice_tools
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 it states the action ('send an overdue payment reminder'), it lacks critical details: whether this triggers actual email delivery, requires specific permissions, has rate limits, affects invoice status (e.g., marks as reminded), or provides error handling. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by a bullet-point list of parameters and a returns section. Each sentence earns its place by explaining functionality or parameters. However, the 'Returns' section is vague ('Response from the send overdue reminder request'), which slightly reduces efficiency.

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 complexity (6 parameters, mutation action) and lack of annotations/output schema, the description is moderately complete. It covers parameter semantics adequately but misses behavioral aspects like side effects, error conditions, and usage context. For a tool that sends emails and potentially updates invoice states, more detail on outcomes and constraints 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 description adds substantial meaning beyond the input schema, which has 0% schema description coverage. It explains each parameter's purpose: 'invoice_id' identifies the target, 'subject' and 'body' define email content, 'additional_emails' lists extra recipients, 'is_send_to_company' controls company copy, and 'custom_client_email' overrides default client email. This compensates well for the schema's lack of descriptions, though it doesn't detail formats (e.g., email validation).

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: 'Send an overdue payment reminder for an invoice via email.' It specifies the verb ('send'), resource ('overdue payment reminder'), and delivery method ('via email'), which distinguishes it from generic email-sending tools. However, it doesn't explicitly differentiate from sibling tools like 'send_invoice', which might handle initial invoice delivery rather than overdue reminders.

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., invoice must be overdue), compare it to 'send_invoice' for initial notifications, or specify conditions like invoice status. Without this context, an agent might misuse it for non-overdue invoices or duplicate communications.

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

Related 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/norman-finance/norman-mcp-server'

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