Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@datagate-mcp list my most recent customers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server and CLI for the DataGate billing platform API.
MCP server — read-only tools for Claude Desktop, Claude Code, and other MCP clients
CLI — full CRUD for managing customers, invoices, products, agreements, sites, and payments
pip install datagate-mcpOr run the MCP server directly:
uvx datagate-mcpRelated MCP server: acronis-mcp
Set two environment variables:
Variable | Description |
| Bearer token from DataGate portal |
| Integration GUID from DataGate portal |
| (optional) Override base URL (default: |
Add to claude_desktop_config.json:
{
"mcpServers": {
"datagate": {
"command": "uvx",
"args": ["datagate-mcp"],
"env": {
"DATAGATE_API_KEY": "your-api-key",
"DATAGATE_CLIENT_ID": "your-client-id"
}
}
}
}Add to .mcp.json:
{
"mcpServers": {
"datagate": {
"command": "uvx",
"args": ["datagate-mcp"],
"env": {
"DATAGATE_API_KEY": "your-api-key",
"DATAGATE_CLIENT_ID": "your-client-id"
}
}
}
}# List customers
datagate customers list
datagate customers list --page 2 --page-size 25
# Get a customer
datagate customers get <customer-id>
# Search invoices
datagate invoices search --invoice-date 2026-01-01
datagate invoices search --period-start 2025-12-01 --period-end 2025-12-31
# Invoice line items
datagate invoices details <invoice-id>
# List products (optionally by customer)
datagate products list --customer-id <id>
# JSON output
datagate --json customers listAll write commands require --confirm:
datagate customers create --name "Acme Corp" --code "50099"
datagate customers update <id> --data '{"companyName": "Acme Corp LLC"}'
datagate customers delete <id> --confirm
datagate products create --customer-id <id> --code "Internet 1Gb"
datagate sites create --customer-id <id> --name "123 Main St"
# Payments are IRREVERSIBLE — void only via DataGate portal
datagate payments create --customer-id <id> --amount 100.00 --confirmTool | Description |
| List customers with pagination |
| Get single customer by ID |
| Search invoices by date/period |
| Invoice with line-item transactions |
| Products with pricing, filterable by customer |
| Single product with charges |
| Billing agreements, filterable by customer |
| Single agreement |
| Physical locations, filterable by customer |
| Portal login accounts |
| Service items |
| Rate cards |
| Kit templates |
60 calls/minute
5,000 calls/day
The client automatically paces requests to stay within limits.
MIT
Get a single agreement by ID.
Note: DataGate returns this as an array (API quirk).
| Name | Required | Description | Default |
|---|---|---|---|
| agreement_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important API quirk (returns as array) beyond the schema. No annotations are provided, so the description carries the full burden and adds valuable 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loaded purpose, and a critical behavioral note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter and no output schema, the description covers purpose and a behavioral quirk. It is sufficient but could mention outcome details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning about the agreement_id parameter (e.g., format, source). It only restates the ID role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), resource (agreement), and identifier (ID). It distinguishes from sibling tools like list_agreements for listing multiple.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single agreement by ID, but does not explicitly state when to use it versus alternatives like list_agreements or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single customer by ID (UUID).
Returns full customer details including address, agreement, account manager, delivery method, tax rate, and custom fields.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes a read-only operation ('Get') and lists return fields, which is sufficient for a simple get-by-ID tool. No behavioral traits like permissions or rate limits are disclosed, but the tool's nature is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and then listing return fields. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description adequately explains the parameter (customer_id as UUID) and the return fields (full customer details including address, etc.). It is complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by specifying that customer_id is a UUID. However, it does not explain constraints or format beyond that. For a single-parameter tool, this provides some value but not comprehensive guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('customer') and specifies that it retrieves a single customer by ID (UUID). It lists the returned fields, distinguishing it from sibling tools like list_customers (list) and get_agreement (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a single customer by ID, but does not explicitly state when to use this vs. alternatives (e.g., list_customers). The context of sibling tools makes it clear, but explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full invoice details with line-item transactions.
Returns the invoice header plus transactions array. Each transaction has productCode, productLabel, quantity, amount (commission base), tax, and total.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the return structure (invoice header and transactions array with fields) but does not disclose behavioral traits such as read-only nature, error handling, or required permissions. With no annotations, the description carries the burden but only partially meets it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core purpose and then listing return fields. No unnecessary information is present, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return structure adequately for a simple get operation but lacks details on error scenarios, pagination (if any), and guarantees about the operation. Given the complexity (single param, no output schema), the description is minimally sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the only parameter 'invoice_id'. The description does not add any meaning about the parameter's format, constraints, or source. The tool's purpose implies the parameter is an identifier, but no extra guidance is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full invoice details including line-item transactions, using a specific verb and resource. It implicitly distinguishes from siblings like 'search_invoices' by focusing on a single invoice with line items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not specify prerequisites, such as needing an invoice ID, or contrast with sibling tools like 'search_invoices' or 'list_agreements'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single product by ID with full charge details.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'full charge details' but does not explain what that includes, nor does it cover authentication, rate limits, or error behavior (e.g., what happens if the product ID is invalid or missing).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the core action. However, it could be improved by adding a brief note on what 'full charge details' entails.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 param, no output schema, no annotations), the description is incomplete. It lacks details on return format, error handling, and the scope of 'full charge details.' A more complete description would specify the expected response fields or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only says 'by ID' without clarifying the required format or any constraints on product_id. The parameter name is self-explanatory, but the description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a single product by ID with full charge details,' specifying the verb (Get), resource (product), and additional content (full charge details). This distinguishes it from sibling tools like list_products and tools targeting different resources (e.g., get_agreement, get_customer).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single product's full details are needed, but it does not explicitly state when not to use it or mention alternatives. No guidance on choosing this over list_products or search_invoices is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List billing agreements.
Most customers have a single "Default Agreement" with billing frequency and payment terms. Filter by customer_id to see a specific customer's agreements.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | No | ||
| page | No | ||
| page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the tool lists agreements and mentions customer_id filtering but does not describe pagination, ordering, or response structure. This is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Front-loaded with the primary action. Every word adds value, achieving excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 optional parameters and no output schema. The description covers the main purpose and key parameter. Missing pagination details are a minor gap, but overall adequate for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains the customer_id parameter for filtering, but page and page_size are not addressed. This partial compensation leads to a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists billing agreements, a specific verb and resource. The additional note about filtering by customer_id further clarifies scope, differentiating it from siblings like get_agreement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that most customers have a 'Default Agreement' and directs filtering for specific customers. Implicitly guides usage without explicitly naming alternatives, but the context is sufficient for an AI agent to decide when to use this tool versus get_agreement or list_customers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all customers with pagination.
Returns customers with company name, code, address, active status, and billing config. Default page_size is 50, max varies by DataGate config.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses return fields (company name, code, address, active status, billing config) and pagination behavior (default page_size of 50, max varies). However, it does not mention read-only nature, authentication requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundancy. It front-loads purpose and pagination, then lists return fields, then default and max behavior. Concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return fields and basic pagination, but lacks details on ordering, filtering (or lack thereof), and any implicit assumptions (e.g., returns all customers without filters). For a simple list tool without output schema, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add value. It explains that page_size has a default of 50 and max varies by configuration, adding useful context. However, the page parameter is not described beyond its default value in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'customers' with pagination. However, it does not explicitly differentiate from sibling tools like get_customer or search_invoices, though the name implies listing vs single retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as get_customer for a single customer or search_invoices for invoice-related queries. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List portal login accounts for customers.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'List', implying a read operation. It does not disclose pagination behavior, rate limits, or any other traits beyond the basic operation, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the key action. It is concise with no wasted words, though it could benefit from slightly more detail without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema, but the description omits important context like what constitutes a portal login account, the relationship to customers, or the nature of the returned data. It feels incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds nothing about the parameters (page, page_size). Neither their meaning, format, nor usage is explained, forcing reliance on schema defaults alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists portal login accounts for customers, using a specific verb and resource. It is distinct from sibling tools like list_customers or list_products, but does not explicitly differentiate its scope from similar list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description merely states the function without context for selection or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List kit templates.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it offers none. It does not mention pagination behavior, rate limits, ordering, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but under-specified. It fails to earn its place as it provides no value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema, annotations, and parameter documentation, the description is severely inadequate. It does not help an agent understand what the tool returns or how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters (page, page_size). It does not explain pagination or default values, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List kit templates' merely restates the tool name without adding specificity or distinguishing it from sibling tools like list_products or list_agreements. It lacks a specific verb-resource combination that clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., when to list templates vs. get a single template). There is no context for usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products/services with pricing.
Optionally filter by customer_id (UUID). Products include charges with sell amounts, which represent recurring or one-time billing.
Args: customer_id: Filter to a specific customer's products. page: Page number (1-indexed). page_size: Results per page (default 50).
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | No | ||
| page | No | ||
| page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the read operation, filtering, and pagination but omits behavioral traits such as authentication requirements, rate limits, or whether the call is destructive. Given the lack of annotations, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two concise sentences and a structured args list. Every part serves a purpose with no redundancy. It could be slightly shorter, but the structured format aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description provides a reasonable overview of the tool's purpose, filtering, and pagination. It lacks details on sorting, response format, or edge cases, but for a list tool with simple parameters, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description adds value by explaining the purpose and defaults of all three parameters: customer_id as a UUID filter, page as 1-indexed integer, page_size default 50. It provides more meaning than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List products/services with pricing', specifying the verb 'list' and the resource 'products/services with pricing'. It distinguishes from siblings like 'get_product' (single product) by implying a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through optional filters (customer_id) and pagination but does not explicitly state when to use this tool vs alternatives like 'get_product' or 'list_agreements'. No exclusion criteria or context for when not to use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List rate cards.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden to disclose behavior. It merely repeats the name and omits essential details like pagination, results ordering, rate limits, or safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified; its extreme brevity sacrifices necessary information for conciseness, making it unhelpful for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of pagination parameters and no output schema, the description should explain return values and pagination behavior. It provides nothing, rendering it completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description fails to explain the 'page' and 'page_size' parameters, leaving their purpose implicit despite being critical for correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List rate cards' is a near-tautology of the tool name 'list_rate_cards', offering no additional specificity or differentiation from sibling tools like list_products or list_customers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as get_agreement or list_agreements, nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List service items, optionally filtered by customer or site.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | No | ||
| site | No | ||
| page | No | ||
| page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits such as pagination, response format, or whether it is read-only. With no annotations, the description should provide more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose without any extraneous words. It is appropriately short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about pagination, default ordering, and the full set of parameters. Given the absence of an output schema and annotations, the description is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the description hints at two filtering parameters (customer_id and site), it does not explain the pagination parameters (page and page_size) or their semantics. With 0% schema coverage, more explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists service items and mentions optional filtering by customer or site, which distinguishes it from sibling list tools like list_agreements and list_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor are there any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List physical site locations.
Sites are addresses associated with customers. Filter by customer_id to see a specific customer's locations.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | No | ||
| page | No | ||
| page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description should fully disclose behavior. It mentions sites are addresses associated with customers and the filtering capability, but does not state that the operation is read-only, whether pagination is supported, or default response behavior. This omission leaves the agent uncertain about side effects and output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loaded with the core purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description lacks completeness: it fails to mention pagination, default parameter values, or what the response looks like (e.g., list of addresses). For a list tool with no output schema, more detail is needed to guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains customer_id's purpose ('filter by customer_id to see a specific customer's locations'), but does not describe page and page_size at all. The agent remains unclear about pagination behavior, leaving parameter semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists physical site locations, explicitly identifies the resource (sites) and action (list). It distinguishes from siblings like list_customers or list_agreements, as no other tool lists sites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use the filter: 'Filter by customer_id to see a specific customer's locations.' However, it lacks explicit when-not-to-use or alternatives, but the sibling context makes the usage fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search invoices with optional filters.
Args: invoice_date: Exact invoice date (YYYY-MM-DD). For monthly billing, use the 1st of the month (e.g., "2026-01-01" for December billing). period_start: Billing period start date (YYYY-MM-DD). period_end: Billing period end date (YYYY-MM-DD). page: Page number (1-indexed). page_size: Results per page (default 50).
Returns invoices with number, dates, customer, amounts, and status.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_date | No | ||
| period_start | No | ||
| period_end | No | ||
| page | No | ||
| page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It explains pagination and return fields, but does not disclose whether filtering logic is AND/OR, default sorting, or rate limits. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, and the Args list is structured and clear. Each line is necessary, though the return sentence could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists return fields adequately. However, it lacks details on filtering logic (AND/OR), sorting, and pagination limits beyond defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema, especially for invoice_date (monthly billing nuance) and period_* date formats. It clarifies default values for page and page_size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search invoices with optional filters', which is a specific verb-resource combination. It distinguishes from siblings like get_invoice_details (detailed retrieval of a single invoice) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. There is no mention of when not to use it or comparison with sibling tools like get_invoice_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1get_agreementget_customerget_invoice_detailsget_productlist_agreementslist_customer_userslist_customerslist_kit_templateslist_productslist_rate_cardslist_service_itemslist_sitessearch_invoicesScored across 13 tools
Each tool targets a distinct resource or action: get/list for individual vs collection, with separate tools for agreements, customers, invoices, products, sites, etc. No overlap in functionality.
All tools follow a consistent verb_noun pattern (get_*, list_*, search_*) using snake_case, making the set predictable and easy to navigate.
13 tools cover the core entities of a billing/agreement domain without being excessive. Each tool serves a clear purpose within the scope.
Read operations are present for most entities, but missing individual get endpoints for customer users, kit templates, rate cards, service items, and sites reduces retrieval completeness. No write/update tools, though likely intentional.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Autumn — read customers, plans, balances & invoices; track usage and attach plans.
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
