automic-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUTOMIC_API_KEY | Yes | Automic API key. Required. | |
| AUTOMIC_BASE_URL | No | Base URL for the Automic Registry Platform API. | https://api.automic.com.au |
| AUTOMIC_CLIENT_ID | Yes | Automic API client ID. Required. Create an app with Read access in the Automic issuer portal. | |
| AUTOMIC_REPORT_DIR | No | Directory where reports and transaction payment list results are written. Files are created with mode 0600 and may contain investor personal data. | $TMPDIR/automic-mcp-reports |
| AUTOMIC_CLIENT_SECRET | Yes | Automic API client secret. Required. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Read-only Automic registry access. Use list_issuers and list_securities to find IDs. Some results contain investor personal data.
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 |
|---|---|
| list_issuersA | List issuers this API app can access. |
| list_securitiesA | List an issuer's securities with holder counts and issued capital. |
| get_daily_pricesB | Daily prices (OHLC, volume, NAV, application/redemption) for a security. Max 20 per page. |
| get_top_holdersA | Top holders of securities as of a date. Max 50. Holder numbers are masked without the 'view holder number' permission. |
| list_distributionsB | Approved distributions in a record-date range, with dates, DRP details and components. |
| get_distribution_payment_listB | Per-holder payments for a distribution: components, tax, DRP, net amount, payment method. Saved to a JSON file; returned inline if small. Contains investor personal data. |
| build_registration_detailsB | Format names, designation and address into a registration details string. Creates nothing. |
| run_register_listing_reportA | Register listing for securities as of a date. Async: waits up to waitSeconds, else returns a reportId for get_report. Saved to a JSON file; returned inline if small. Contains investor personal data. |
| run_transaction_listing_reportB | Holding movements for securities over a date range. Async, same as run_register_listing_report. |
| run_fund_cash_flow_reportC | Fund applications and redemptions with pending and completed totals. Async, same as run_register_listing_report. |
| get_reportA | Check status of an async report and download it when ready. |
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 11 tools
Most tools target a distinct resource or report type, and the three run_*_report variants are separated by their subject matter. The only mild friction is between list_distributions and get_distribution_payment_list (aggregate vs per-holder payment detail) and the generic get_report, but descriptions resolve both.
Every name is snake_case verb_noun (list_issuers, get_daily_prices, run_register_listing_report), with consistent verbs chosen for the action type: list for collections, get for single fetches, run for async reports.
Eleven tools is well within the sweet spot for a domain-specific data server, and each tool covers a distinct data product (issuers, securities, prices, holders, distributions, payments, three report types, report retrieval, plus a formatting helper).
The core read workflow is covered end to end: issuers to securities to prices/holders, distributions to per-holder payments, and async reports with a retrieval tool. Minor gaps exist — no single-record get_issuer/get_security detail endpoint and no holder lookup — but agents can work around these via the list tools.