Ask what is running on Vultr in a region, and where a DNS record points.
Connect Vultr with an API key and Memtro reads cloud instances with plan, region, OS, IPs, power and status, bare-metal servers, Kubernetes clusters with their node pools, DNS domains and their records, and snapshots. A kubeconfig is never returned, and billing is not read. It reads on demand and there is no hourly sync. When you ask, and once an administrator has granted the action by name, it can start, halt or reboot instances, take snapshots, which are billed monthly, and add, change or delete live DNS records. Destroying an instance or deleting a snapshot is permanent.
Ask in plain English from chat, your editor, a scheduled job or your own agent. The model picks the right Vultr tool, reads what it needs, and answers with the source cited.
These tools change something in Vultr. The model is told to use them only when you ask for exactly that, and an administrator grants each one by name to the teams that may use it; a personal connection acts only after its owner allows it.
Once Vultr is connected, these are the kinds of things people ask. Plain questions, no syntax. If the answer lives partly in another system you have connected, Memtro looks there too.
What instances are running in Frankfurt, and on which plans?
Where does api.acme.com point?
Which Kubernetes clusters are on an older version?
Is DNSSEC on for all our Vultr domains?
Point status.acme.com at 203.0.113.40
A customer reports that Acme's status page is unreachable, and support asks where it points. Memtro reads the domain's DNS records on Vultr and returns the A record's address and TTL, and the instance in Amsterdam that holds that IP.
Dan Fletcher has moved Acme's status page to a new server and asks Memtro to point the name at it. Memtro reads the current A record so it can be put back, then changes its address, and resolvers pick up the new one within the old TTL.
The teams that lean on Vultr most, a question each of them asks, and what they connect beside it.
A record in Vultr is rarely the whole story. Connect the systems that hold the rest and Memtro checks them together, then remembers what it learned so the next question starts further along.
Using something else for the same job, or both? Each connector has its own tools; connect as many as you like.
UptimeRobot
Honeycomb
Cronitor
FireHydrant
StatusCake
GlitchTip
GLPI
Langfuse
LibreNMS
NetBox
Snipe-IT
Woodpecker CI
Zabbix
LangSmith
Helicone
GrowthBook
Drata
Intruder
GitGuardian
Secureframe
ilert
JumpCloud
ConfigCat
Split
Aikido Security
Astronomer
Comet Opik
CrowdStrike Falcon
Detectify
Domotz
LambdaTest
LangWatch
LlamaCloud
Logz.io
Lunary
NinjaOne
Northflank
Portkey
PromptLayer
PRTG Network Monitor
Raygun
Retell AI
Runpod
Shodan
Spike.sh
Squadcast
Tenable
UpGuard
Uptime.com
Vanta
Zenduty
Cortex
WorkOS
Kandji
Automox
Huntress
SimpleMDM
Healthchecks.io
Rapid7 InsightVM
ZenhubIn my.vultr.com open Account → API, enable the API if it is off, and copy the key. It has its user's access, so it can do whatever that user can. A sub-user's key is limited to that user's ACLs
Under Access Control on the same page, allow Memtro's addresses (or all IPv4 and IPv6), or every call is refused
In Memtro open Connections → Vultr, paste the API key and connect
Ask what is running in your main region
Chat in the dashboard, the OpenAI-compatible API, scheduled jobs, and any MCP client: Claude Code, OpenCode, Cursor, Claude Desktop. The Vultr tools are the same everywhere.
Only when you ask, and only what it has been granted: start a Vultr instance; halt (power off) a Vultr instance; reboot a Vultr instance; delete a Vultr instance permanently; take a snapshot of a Vultr instance; delete a Vultr snapshot permanently; add a DNS record to a Vultr-hosted domain; change a DNS record on a Vultr-hosted domain; delete a DNS record from a Vultr-hosted domain. Every other tool reads, searches or lists. The Connections page labels the tools that act, an administrator grants each one by name to the teams that may use it, and a personal connection acts only after its owner allows it.
A personal connection serves only your own requests. A shared connection serves the organisation: everyone, or only the teams an admin chooses. Admins can always add shared connections; other members need the permission.
Credentials are encrypted at rest. Tool results are cached briefly so agent loops do not repeat identical calls, and the facts the model extracts are saved to your organisation's memory with provenance (system, record and link) so they can be checked and superseded.
API key. In my.vultr.com open Account → API, enable the API if it is off, and copy the key. It has its user's access, so it can do whatever that user can. A sub-user's key is limited to that user's ACLs.
Seven-day free trial, then one monthly price per organisation. Connectors, jobs and memory are never metered.
Sign in, add a provider key, create an API key and point your tools at Memtro. It takes about five minutes.
7-day free trial · card on file, nothing charged until it ends · cancel any time
