@aiotic/mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AIOTIC_API_KEY | No | API key for the test tenant to enable tenant mode (e.g., mock-integration-key). | |
| AIOTIC_BASE_URL | No | Base URL of your test tenant or the AIOTIC Python SDK mock to enable tenant mode (e.g., http://localhost:8080). | |
| AIOTIC_MCP_HOST | No | Address the HTTP server listens on. Default is 127.0.0.1. | |
| AIOTIC_MCP_GEOIP_DB | No | MMDB country database for the usage log. Default is none. | |
| AIOTIC_MCP_MAX_BODY | No | Largest request body, in bytes, for the HTTP transport. Default is 262144. | |
| AIOTIC_MCP_BLOCKLIST | No | File with addresses and CIDR ranges to refuse. Default is none. | |
| AIOTIC_MCP_LOG_MAX_MB | No | Total size limit of the usage log, in MB. Default is 512. | |
| AIOTIC_MCP_RATE_BURST | No | Requests per client address: burst size for the HTTP transport. Default is 60. | |
| AIOTIC_MCP_TRUST_PROXY | No | Peers whose X-Real-IP and X-Forwarded-For headers may be believed: 1 (loopback), gateway (the container's default gateway), private, CIDR ranges or any. Default is none. | |
| AIOTIC_MCP_ALLOW_WRITES | No | Set to true to enable write tools. Default is false. | |
| AIOTIC_MCP_ALLOWED_HOSTS | No | Host header allow-list for the HTTP transport. Default is any host. | |
| AIOTIC_MCP_ANALYTICS_DIR | No | Usage log directory, one JSON line per request; node dist/stats.js --dir <dir> --days 30 aggregates it. Default is off. | |
| AIOTIC_MCP_LOG_DAY_MAX_MB | No | Size limit of the usage log per day, in MB. Default is 128. | |
| AIOTIC_MCP_RETENTION_DAYS | No | Days the usage log is kept. Default is 180. | |
| AIOTIC_MCP_ALLOWED_ORIGINS | No | Browser origins that may call the HTTP transport; a request with any other Origin gets 403. Default is none. | |
| AIOTIC_MCP_ALLOW_DANGEROUS | No | Set to true to enable deletes and send_order_to_erp; also requires confirm: true in the call. Default is false. | |
| AIOTIC_MCP_RATE_PER_SECOND | No | Requests per client address: steady rate for the HTTP transport. Default is 1. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_guideA | Full-text search over the guide (sections). Returns page, heading, URL and a snippet. Use before answering any AIOTIC integration question. |
| get_pageA | Return one guide page as Markdown. Paths look like /receiving/erp-receive-endpoint or /sdk/pipeline. Use list_pages to discover paths. |
| list_pagesA | All pages of the guide with section, title and one-line summary, in reading order. |
| list_endpointsA | Every public AIOTIC endpoint (method, path, summary, auth) plus the outbound webhooks you implement. Optional tag filter: health, orders, order-status, erp, rejected, customers, products, customer-products, email-watcher, webhooks. |
| get_endpointA | Full contract of one endpoint by operationId (e.g. sendOrderToErp, uploadOrder, upsertCustomer) or "METHOD /path", or a webhook name (erpReceiveOrder, processingCompleted). Schemas are inlined. |
| get_schemaA | One JSON schema from the API components, with $refs inlined. Names: Address, ClassifiedEmail, Customer, CustomerListResponse, CustomerProduct, CustomerProductListResponse, CustomerProductUpsert, CustomerSearchResponse, CustomerUpsert, EmailClassificationResponse, ErpAddress, ErpCustomer, ErpOrderItem, ErpPurchaseOrder, ErpReceiveRequest, ErpReceiveResponse, ErpRecipient, ErpSendResponse, ErpShippingDetails, ErrorResponse, FetchAllEmailsResponse, HTTPValidationError, OrderCustomer, OrderGroup, OrderItem, OrderListResponse, OrderRef, OrderRetryBody, OrderStatus, OrderStatusValue, OrderUploadBody, OrderUploadResponse, ProcessingWebhookRequest, Product, ProductListResponse, ProductUpsert, PurchaseOrder, RawEmailClassifyBody, RawEmailUploadBody, RawUploadRejection, RejectedEmailListResponse, ReprocessResponse, ShippingDetails, ShippingRecipient, Supplier, SystemStatus, ValidationError. |
| get_exampleB | Real payload samples. Names: erp-receive-request, erp-receive-response-accepted, erp-receive-response-rejected, order-status, upload-response-split, raw-upload-rejection, customer-upsert, product-upsert, customer-product-upsert, sync-events. |
| get_status_lifecycleB | Status values, which are sendable / landed / terminal, and the transitions between them. |
| tenant_healthA | GET /healthcheck and /system-status of the configured tenant (no key needed). |
| get_order_statusB | GET /order_status/{request_id} — status, extracted purchase order (result), erp_ref, errors. |
| list_ordersC | GET /order_status/list — newest first. |
| get_order_groupD | GET /order/group/{email_group_id}. |
| list_rejected_emailsD | GET /rejected/list. |
| get_customerD | GET /customer/{number}. |
| search_customersC | GET /customer/search/{query} — fuzzy search over your customer records, comparable to how AIOTIC matches order senders. |
| list_productsD | GET /product/list. |
| get_productD | GET /product/{item_number}/{language_code}. |
| list_customer_productsC | GET /customer-product/list with optional filters. |
| upsert_customerC | PUT /customer/{number}. Requires AIOTIC_MCP_ALLOW_WRITES=true. |
| upsert_productC | PUT /product/{item_number}/{language_code}. Requires AIOTIC_MCP_ALLOW_WRITES=true. |
| upsert_customer_productC | PUT /customer-product/{customer_number}/{customer_item_number}. Requires AIOTIC_MCP_ALLOW_WRITES=true. |
| upload_orderB | POST /order/upload with one text/markdown file built from the given content — for exercising the flow against the mock/test tenant. Requires AIOTIC_MCP_ALLOW_WRITES=true. |
| retry_orderB | POST /order/retry/{request_id}. Requires AIOTIC_MCP_ALLOW_WRITES=true. |
| reprocess_rejected_emailC | POST /rejected/{request_id}/reprocess. Requires AIOTIC_MCP_ALLOW_WRITES=true. |
| send_order_to_erpA | POST /erp/send/{request_id} — calls the tenant's ERP receive endpoint. Requires AIOTIC_MCP_ALLOW_DANGEROUS=true and confirm:true. |
| delete_customerB | DELETE /customer/{number}. Requires AIOTIC_MCP_ALLOW_DANGEROUS=true and confirm:true. |
| delete_productB | DELETE /product/{item_number}/{language_code}. Requires AIOTIC_MCP_ALLOW_DANGEROUS=true and confirm:true. |
| delete_customer_productA | DELETE /customer-product/{customer_number}/{customer_item_number}. Requires AIOTIC_MCP_ALLOW_DANGEROUS=true and confirm:true. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 28 tools
Tools are largely distinct: documentation tools (search_guide, get_page, list_pages) vs. contract tools (list_endpoints, get_endpoint, get_schema, get_example) vs. domain operations are clearly separated by resource and action. The only mild overlap is among the order-flow write tools (retry_order, upload_order, send_order_to_erp, reprocess_rejected_email), but their descriptions distinguish them well enough.
The set follows a consistent snake_case verb_noun pattern (list_orders, get_customer, upsert_product, delete_customer, search_customers). The main deviation is tenant_health, which uses a noun_noun form rather than a verb prefix, but everything else is predictable.
At 28 tools this is heavy and sits at the upper edge of what an agent can scan efficiently. The breadth is partly justified by the wide domain (full docs surface plus orders, customers, products, and rejected-email operations), and most tools earn their place, but the count is borderline excessive.
Coverage is strong: full CRUD for customers, products, and customer-products, plus order lifecycle (upload, retry, send, status, group), rejected-email handling, and comprehensive docs/contract tooling. Minor gaps remain (no explicit order deletion, webhook configuration management, or batch operations), but core workflows have no dead ends.