I use AI coding tools such as Claude, Codex, and Cursor, and I want them to work with the systems behind my applications: databases, server logs, APIs, and cloud services.
MCP makes those connections useful. But once several servers and environments are involved, I need to answer a few practical questions:
Those questions are the reason I am building GateRook, an open-source desktop MCP gateway.
I am the author of the project. In this article, I want to explain the access model, walk through a database-and-logs workflow, and describe the boundaries of the approach.
A database connection is useful on its own. Add an SSH log server, a cloud integration, a few external MCP servers, and separate development and production environments, and there are more decisions to keep track of.
Each integration may have its own credentials, tool names, permission model, approval behavior, and logs. Using several AI clients adds another place to configure and review those choices.
The difficult part is understanding the combined access you have granted.
A request such as “investigate this failed job” might lead to several calls: discovering a schema, reading records, searching logs, inspecting infrastructure, and proposing a change. The natural-language request does not specify every step in advance.
A chat transcript can explain what the assistant thinks it did. I also want an execution history that shows the tools it actually called, their arguments, the target environment, and the decisions made along the way.
For me, useful AI access needs three things together: a defined scope, control over changes, and a reviewable history.
GateRook runs as a desktop application between the AI client and the connected services.
You add connections in GateRook, choose which connections and tools an endpoint exposes, and connect the AI client to that endpoint. The gateway handles authentication, evaluates the applicable rules, and records the calls passing through it.
An endpoint can provide one entry point for several resources. You can also keep separate endpoints for different purposes: for example, development work and production investigation.
That distinction matters. “One place to connect” should not mean “every client gets access to everything.”
A small setup might look like this:
| Resource | Access for an investigation |
|---|---|
| Development database | Read queries; changes require approval |
| Selected application log files over SSH | List, read, and search within configured limits |
| Production database | A separately scoped endpoint with stricter permissions |
| External MCP tools | Only the reviewed tools needed for the task |
GateRook includes built-in connectors for databases, logs, SSH, APIs, and cloud services. It can also connect external MCP servers, so existing integrations can participate in the same access model.
The Overview groups connections by endpoint and shows which AI applications are connected.
One of the main things I wanted was a place to inspect all tool calls routed through GateRook, including calls that were denied or failed.
The Activity view brings together the AI client, endpoint, connection, environment, tool, arguments, policy decision, duration, and outcome information. You can filter the history to investigate a particular client, connection, tool, or time period.
This is useful for ordinary debugging as well as access control.
If the assistant produces an unexpected answer, the history helps you check whether it queried the wrong environment, searched too narrow a time range, encountered a policy denial, or received an error. If it proposes a change, you can inspect the calls that led up to that proposal.
Activity shows calls across connections and clients, including successful calls, policy denials, and errors.
Recording denied attempts matters too. A rejected operation is part of the explanation of what happened.
The scope here is specific: GateRook records activity that passes through its gateway. An agent's separate terminal commands or direct connections are outside that history. Stored payloads also have masking and size limits; a useful audit trail does not require retaining every byte of sensitive output.
GateRook requires review for changes by default.
When a call needs approval, the application presents the prepared action and its target. For a database update, that means being able to inspect the SQL, the connection and environment, the reason approval is required, and available impact information.
Consider this illustrative development-database change:
UPDATE users
SET email = 'new-address@example.com'
WHERE id = 42;
Before approving it, I want to check the target database, the table, the condition, and the value being written. A generic “the assistant wants to use a tool” prompt would leave too much of that review implicit.
The approval is tied to the prepared action stored by the gateway. After approval, GateRook executes that stored payload, with the applicable checks, instead of asking the model to reconstruct the command.
You can approve or deny the request. An unanswered request expires; waiting does not turn into permission.
A pending SQL request shown in the AI client. “Approve in GateRook” opens the app’s review screen; the action remains unexecuted until you approve it there.
Approval behavior is configurable. GateRook has explicit per-tool Bypass settings, and temporary bypass is available for specific tools and connections in development and staging. Bypass skips the human approval step while retaining applicable policy limits.
That makes the chosen mode part of the access decision. For a workflow where I want to review every change, I keep those tools in approval mode.
To search logs or query a database, the model needs access to an allowed operation. It does not need the underlying authentication material in the conversation.
With GateRook, connection credentials are configured on the gateway side. The model works with connection names and permitted tool arguments; GateRook handles authentication to the selected service.
That means I do not need to paste database passwords, API keys, or SSH private keys into a prompt. Stored secrets are encrypted, and the application can also reference supported external secret stores.
There is an important distinction between connection credentials and the data a tool returns. A database row or log line can itself contain sensitive information. Credential isolation therefore works alongside access restrictions, masking rules, and bounded results.
The claim is that GateRook keeps the configured infrastructure credentials out of the model's tool arguments. It is not a guarantee that every possible secret in arbitrary source data will be detected, or that a separate agent with broad access to the same computer cannot reach files through another route.
The SSH log connector is a concrete example of this approach.
You configure SSH authentication in GateRook and explicitly select the remote files the connection may access. The AI can then use structured tools such as:
ssh_logs_list to discover the selected files.ssh_logs_read to read a bounded portion of a file.ssh_logs_search to search by text, level, and event time.
For example, after configuring a connection named server-logs and selecting app.log, a search could use these arguments:
{
"connection": "server-logs",
"file": "app.log",
"query": "timeout",
"matchMode": "literal",
"levels": ["ERROR", "WARN"],
"from": "-1h",
"to": "now",
"maxLines": 50
}
The request identifies the connection, file, filters, and desired output size. It contains no SSH private key.
GateRook builds the bounded commands used to read the selected files. The AI cannot supply an arbitrary shell command through these dedicated log tools.
An SSH log search in Activity, with the client, connection, timing, and structured arguments available for inspection.
The result still needs to be interpreted carefully. Time filters depend on timestamps in the records, and size or time limits can produce partial results. A bounded search returning no matches is not proof that an event never happened.
The SSH log connector guide explains file selection, timestamp parsing, limits, and continuation.
A gateway is more useful if it can work with integrations you already have.
GateRook supports external MCP servers alongside its built-in connectors. You choose which tools are exposed through an endpoint and manage their access modes there.
Connections and tools can be enabled or disabled as the task changes. Tools switched off are not exposed or callable through that endpoint. This gives me a central place to narrow access when an investigation finishes or a resource is no longer needed.
Compatible clients receive tool-list change notifications. Client discovery and caching behavior still vary, so the gateway's enforced permissions and what a client currently displays are separate concerns.
External MCP servers also remain software you must trust appropriately. GateRook requires review of external tool definitions and does not treat an upstream readOnlyHint as proof that an operation is harmless.
Here is an example workflow using those pieces together. It is an illustration of the setup, not a benchmark or an incident report.
Suppose a background job is failing and you want the assistant to compare its database state with its application logs.
This connects the investigation, the proposed action, and the execution record. It also gives the person reviewing the work a place to make a decision outside the assistant's explanation.
The same application includes connection health, environment-aware policies, execution and output limits, a Playground for trying tool calls, and Insights derived from the audit history.
HTTP APIs can be added through OpenAPI import, with the server, authentication, and selected operations reviewed before they become tools.
The architecture document describes the call flow, credential handling, approval model, and implementation boundaries in more detail.
GateRook is still in development. Its current scope is a desktop application for one local user.
There are practical tradeoffs to work through. A central gateway becomes an additional component to configure and trust. Approval prompts need enough detail to support a real decision without making routine work exhausting. Audit history needs enough context to explain events while respecting sensitive data and retention limits.
I want the access model to stay understandable as the number of connections grows. At any point, I should be able to see what an AI client can reach, review a consequential action, and trace what actually happened.
If you use several MCP servers, I would be interested in how you handle that today. Which operations do you review manually, and what information do you need in a tool-call history to investigate a problem?
GateRook is available under the Apache 2.0 license.