MCP Architectural Principles

Last update:
3/9/2026 · 2 min read

---

IN THIS ARTICLE

These are the three design principles behind Albato MCP's tool set: why calls are batched, why behavior lives in the tool descriptions rather than external docs, and how authentication is scoped to keep your users' credentials safe. Read this alongside the MCP Tools Reference and MCP Usage Scenarios for the full picture.

Design principles

• Minimize tool calls.

Each tool call costs one LLM inference, roughly 3 to 8 seconds. Every tool is designed so the agent gets as much of the information it needs as possible in a single call. find_action combines three operations, finding the app, its actions, and the user's existing connections, into one. Bulk mode lets a single call cover multiple apps or actions in parallel instead of running them one by one.

• Tool descriptions as the sole instruction.

The server works with any MCP-compatible agent, and there's no guarantee the client's system prompt is configured correctly. So every behavioral rule, calling get_action_schema before run_action_sync, using individual words in fieldFilter, checking connection status only once instead of polling, is written directly into the tool descriptions themselves rather than left to external instructions.

• Authentication via virtual keys.

With a virtual key (mcp_vk_...), the user's real Albato token is stored encrypted on the server and never leaves it. Your MCP client is configured with the virtual key instead, used purely as a transport-level Authorization header. Neither your MCP client nor the agent's underlying model ever handles the real Albato token, and the key can be revoked at any time without changing the token itself. For backward compatibility, a direct Albato token is also accepted; in that case the server doesn't store it, and behavior stays as before.

See the Virtual Keys guide for issuing and revoking keys.

Need help? Contact your Albato manager or reach out to the Albato support team.