Skip to main content
Glama
BillingServ

BillingServ MCP

Official

Create or update BillingServ records

billingserv_create

Create or update billing records including support tickets, orders, customers, invoices, quotes, discounts, packages, and groups. Also send invoices or payment reminders via email.

Instructions

Create or update records in BillingServ: support tickets and ticket replies, orders, customers, customer notes, invoices, quotes, discounts, packages, package groups, and package options. Can also send an invoice or payment reminder to a customer by email. This tool changes real billing data and can email customers, so confirm the details with the user before calling it. Only allowlisted endpoints can be called; deleting records and capturing payments are not available through this server.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesJSON body for the endpoint. See billingserv_list_endpoints for each endpoint's required and optional fields. Dotted field names such as cycle.cycle, record.item, or options.id are parallel arrays inside a nested object: pass them either as dotted keys ({"cycle.cycle": [5], "cycle.price": [10]}) or as a nested object ({"cycle": {"cycle": [5], "price": [10]}}); dotted keys are expanded to the nested form before sending.
endpointYesAllowlisted BillingServ write endpoint, relative to /api/v2. All write endpoints use POST.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It warns that the tool changes real billing data and can email customers, requiring user confirmation. It also notes that only allowlisted endpoints are callable and that deletions/payments are unavailable. This discloses key behavioral traits, though it could mention whether it returns created records or errors.

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 (three sentences) and front-loaded: first sentence states purpose and lists record types, second adds email capability, third warns about behavior and limitations. Every sentence adds useful information without redundancy.

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 no output schema, the description doesn't explain return values, but it references billingserv_list_endpoints for detail on required/optional fields. It covers input parameters well and provides necessary caveats. For a creation tool, missing return details is a minor gap, but overall completeness is good for agent usage.

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?

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining dotted field names and how to pass them (nested objects vs dotted keys), and references billingserv_list_endpoints for per-endpoint field details. This goes beyond the schema's own descriptions.

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 title and description clearly state the tool creates or updates various BillingServ record types and can send emails. It distinguishes itself from sibling tools (billingserv_get, billingserv_list_endpoints) which are read/list operations. The description is specific about the resource and action.

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 explicitly states when to use the tool (create/update records, send reminders) and when not to use it (deleting records, capturing payments not available). It advises confirming details with the user before calling, providing clear usage guidance.

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/BillingServ/MCP'

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