Connecting Gmail
The Gmail MCP server, the two Google Cloud gates that let a sign-in succeed and every call still fail, and the one thing it cannot do.
Gmail is in the catalogue on settings → MCP, and connecting it is the same
two presses as any other tool server: add, then sign in on
its own row.
It is the one server where that is not the last step. Google keeps it behind two
gates in your own Google Cloud project, and neither of them is mentioned during
the sign-in. The handshake completes, the panel shows the account connected, and
then every call an agent makes comes back refused.
Both refusals name your project number. Both are one press each. This page is
the order to do them in.
What beafk asks Google for
Two scopes: gmail.readonly and gmail.compose. Read your mail, and write
drafts into it.
Not send. That is not a limit beafk chose, and what it cannot do below is
where that ends up.
Gate one: turn the API on
The refusal reads:
Gmail MCP API has not been used in project 000000000000 before or it is
disabled.
Open the Gmail MCP API in the Google Cloud
console
and press Enable.
Google asks for a few minutes to propagate. A call made straight afterwards can
still be refused with the same sentence.
Gate two: join the preview programme
With the API on, the next refusal is a different one:
Access to this tool requires that your Google Cloud project (000000000000) is
enrolled in the Google Workspace Developer Preview Program.
The Gmail MCP server is not generally available. Enrol the same project in
the Google Workspace Developer Preview
Program.
This one is an enrolment rather than a switch, so it is not instant.
What it can do
Twenty-three tools, and they are all about drafts, reading and filing:
- Drafts — create one, list them, read one back.
- Reading — a message, a thread, a search across threads.
- Filing — labels on a message or a thread, create a label, list them.
- Disposal — trash and untrash, mark and unmark spam.
That is a genuinely useful set. An agent can read the thread you are stuck on,
search for the last time somebody asked the same question, and leave you a
reply written and waiting.
What it cannot do
It cannot send. There is no send tool on the server, at any permission
level. An agent writes the draft, puts it in your Drafts folder, and the press
is yours.
Worth knowing before you ask one to go and email somebody: the answer will be
three drafts and a sentence saying so, and that is the server being honest
rather than the agent giving up.
When it looks connected and is not
This server answers a request for its tool list without a credential — all
twenty-three of them, to anybody who asks. So an agent that can see the tools
may still have no access at all, and "the tools are there" proves nothing.
The tell is the first real call. If a sign-in looks fine and the work does not
happen, the refusal will be one of the two above, and it will name the project.
See when something is wrong for the rest of
that walk.
One inbox per project
A tool server in beafk can be reached with a different identity in different
folders. So a support inbox can belong to the repository it answers for, while
your own mail is not in that project at all.
Same rule as variables: a folder reaches itself and
everything under it. A chat already running keeps the identity it started with —
keeping every CLI in sync says which changes
reach which agent, and when.