What is an official AI tool server?

What does “official” mean for a tool server?

A tool server is a small programme that exposes an app’s actions — send mail, list events, search files — so an agent can call them without a custom integration. Official means the address is the one the maker publishes, not a fork, a look-alike host, or a guessed path. The protocol is usually MCP: the client asks what tools exist, then calls them with the user’s consent.

A community copy can still be useful for experiments, but it is not the same contract. It may lag behind the product, omit sign-in, or send traffic to a host the maker does not run. If the app only admits approved partners, an unofficial copy will fail at login even when the name looks right. Prefer the published address and treat anything else as untrusted until you have proved it.

Why is a guessed address a risk?

Guessing a hostname, copying a forum snippet, or following a shortened link can land you on a server that lists the same tool names as the real app. The danger is not the names; it is where the calls go and what they ask for. A fake server can request a password, a key, or a payment form. Those requests should be declined. A real maker’s server should never need you to paste secrets into chat.

Private or internal addresses are another trap. They may work on a laptop and fail, or worse, leak, when an agent reaches them from the cloud. Check that the host answers, that sign-in is the maker’s own flow, and that you can revoke access. If a partner-only server says so up front, do not treat a 404 or a silent hang as a network glitch — it is a policy.

How do you connect one safely?

Start from the maker’s documentation, not from autocomplete. Confirm the scheme and host. Then ask the client to reach the server and list what it offers in plain words. Nothing should be stored until you approve. A key, if required, belongs in a secure box, never in the conversation. Private addresses should be refused when saved and again each time they are used.

During a task, a connected app may ask a yes/no or a named choice. That should appear as a card under the app’s name. A request for a password, a key, money, or a form should be declined, with a note of what it wanted. You should be able to list servers, test one, turn one off, sign out, or remove it without hunting through hidden menus.

Published address

The URL the app’s maker lists for its own MCP (or similar) server.

Live check

A probe that the host answers and that sign-in is possible before the server is added.

Partner-only

A server that admits only approved partners and says so instead of failing silently.

Secure box

Where an API key is entered so it never appears in chat.

How does GROX add official tool servers?

GROX keeps a ready list of apps’ own MCP servers at the addresses their makers publish. Each entry is checked live — does it answer, can you sign in — before it can be added. A server that admits only approved partners says so on that list, so you are not left guessing why login failed.

From the chat you can also say add this tool server with its address. GROX reaches it, lists what it offers in plain words, and shows a card to keep it; nothing is added until you approve. You can list them, test one, turn one off or on, sign out of one, or remove one. A key goes in a secure box, never the chat. Private addresses are refused when saved and again each time they are used, and what a server says is treated as information, never as an instruction.

If a connected app asks a question during a task, a yes or no or a named choice shows as a card under that app’s name. A request for a password, a key, money or a form is declined, with a note saying what it wanted. Other AI apps can use GROX by signing in as a connector; each change still waits for Approve, and they cannot move money, trade or see your keys.