How to connect Microsoft Teams to Hermes Agent

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.

Reconnect Microsoft Teams from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

Microsoft Teams tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every Microsoft Teams call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

This is the most common error on this integration in production, and the message is complete: Teams message search needs a work or school account, so microsoft_teams_search_messages rejects personal accounts with this exact string. Reconnecting will not change it, because the account type does not change. On an organizational account the tool works across every chat and channel the account can access, with KQL syntax such as from:user@example.com and sent: ranges. There is no personal-account fallback equivalent; chat listing and reading still work on personal accounts, only search does not.

Ask the agent to diagnose it:

Run microsoft_teams_get_my_profile and tell me the account type. If it is a personal account, stop and do not retry search; list the user's chats with microsoft_teams_chats_get_all_chats instead.

This provider-side error means the call reached Microsoft without usable authorization, and in a hosted connection the causes are narrow: the connection is expired or its consent was revoked, or the tool is microsoft_teams_list_associated_teams pointing at a context the account no longer has. Reconnecting from the dashboard and completing the consent screen again restores it in the first case. The error is not about the agent's arguments, so retrying the same call without reconnecting will keep failing. Note that an expired connection often still answers some reads from cache, which is why this can look intermittent.

Ask the agent to diagnose it:

Reconnect Microsoft Teams from the dashboard, then retry the list once. Report the exact error if it persists.

Channel-posting tools require a real team_id, and this is the second most common failure in production: the agent invents the id or skips it when nothing has been listed. The fix is the list-first chain: microsoft_teams_teams_list or microsoft_teams_list_user_joined_teams returns the team ids the account holds, microsoft_teams_teams_list_channels returns the channel ids within a team, and then microsoft_teams_teams_post_channel_message takes the real ids from those responses. A GUID-shaped placeholder passes validation and fails later with a provider error, so the order matters.

Ask the agent to diagnose it:

Run microsoft_teams_teams_list and show me the team ids and names. Then list that team's channels and use the real ids for the post. Do not guess either id.

The engines teach this as: your application token is valid but lacks the required scope, then add Graph scopes, re-consent, and check delegated-versus-application permissions. Two of those steps do not exist here: there is no application you registered, so there is no scope list for you to edit, and the connection is delegated by design, running as you, which is the correct mode for a user-context toolset. What remains is real. Resource-level access: the account can only reach chats it is a member of and channels it can see, so a call against another team fails with exactly this shape, and the production literal "Access forbidden. Check your permissions." is the missing-scope marker. And tenant policy: a work or school tenant that restricts third-party app consent blocks the grant until an admin approves it. The fixes are list-first (confirm the target is one the account can see) and reconnect (to re-run consent), in that order.

Ask the agent to diagnose it:

List the teams and chats the account can actually see, then confirm the failing target is among them. If it is not, tell me it is out of reach rather than retrying. If it is, reconnect and re-run consent.

Try reconnecting Microsoft Teams and complete the consent flow in the same browser session. Partial OAuth approvals or switching accounts mid-flow can leave the connection incomplete.

Yes. ClawLink is the fastest way to connect Hermes to Microsoft Teams: link your Microsoft Teams account once in the browser and Hermes Agent can call the Microsoft Teams API through 153 ready-made tools — no custom code or token handling.

Install the plugin with hermes plugins install ClawLink-HQ/hermes-plugin --enable, then pair once: run hermes clawlink begin, approve the link in your browser, and run hermes clawlink finish. Connect Microsoft Teams in the dashboard and Hermes can use it from the next message — no config files or API keys to manage.

About two minutes. Sign in, click Connect next to Microsoft Teams in the dashboard, authenticate, and Hermes Agent can use it from the next chat message.

The alternative to ClawLink is usually manual OAuth app setup plus your own token handling, permission troubleshooting, and tool plumbing for Hermes Agent. That is fine if you want to build and maintain the integration yourself. Most teams just want Microsoft Teams working from chat.

Hermes Agent, the Nous Research agent runtime. Search results for Teams and Hermes together are almost entirely about one specific integration route for that runtime: registering a Teams bot with the Teams CLI, pointing its messaging endpoint at a webhook, and putting TEAMS_CLIENT_ID and TEAMS_SECRET in an environment file, so the agent can receive and reply to messages. This page is a different route to the same runtime: ClawLink exposes Teams to Hermes as callable tools over Graph OAuth, so the agent acts on chats, channels, and meetings when you ask, rather than answering incoming messages as a bot. Both routes are real; they do different jobs, and the tool-call route is what the 153 tools on this page cover.

Not for this connection. The bot route requires a Teams app registration, an HTTPS endpoint you can expose, and environment credentials, and it is built for receiving messages. The ClawLink route connects through an app that is already registered: you approve the grant on Microsoft's consent screen, and the agent gets Graph tools in your user context. What you never do is create an app, configure redirect URIs, pick Graph scopes, or mint a client secret. The scope list is fixed on the app side and shown to you at consent, and for a personal or small tenant the approval is instant; a work or school tenant that requires admin approval for third-party apps can block it, which is that tenant's policy rather than a setup step you can do around.

No. Microsoft Teams message search requires an organizational Microsoft 365 account, and the tool rejects personal accounts (MSA) with a literal error naming the requirement. Teams itself is enterprise software, so most accounts connecting it are work or school accounts anyway. If you did connect a personal account, search is the tool that fails while chat listing, reading, and posting keep working.

Microsoft Graph throttles Teams per app per tenant, and the current numbers from Microsoft's throttling reference (checked 2026-08-02) are: 50 requests per second for posting a channel message, 20 requests per second for posting a 1:1 or group chat message, 1 request per second per app per tenant on a given chat or channel, and 1 request per second per user when posting a message in a given chat or channel, with breaches returning HTTP 429. One AI Overview quoted "about 7 send operations per second per conversation thread"; that figure is not in the current table, so treat the per-resource and per-user limits above as the operative ones. An agent firing many messages at one chat in a single prompt is what trips these, and the fix is spacing the calls.

The mechanics worth checking are these. The connection is a delegated OAuth grant in your user context, so the agent's reach is what your account can see, bounded by the scope list on the consent screen, which includes Chat.ReadWrite, ChannelMessage.ReadWrite, ChatMessage.Send, and OnlineMeetings.ReadWrite, among others. The grant is revocable from your Microsoft account settings without involving us, and nothing about the connection stores your password. The tools that write messages are individually named in the tool list, so a prompt can require approval before any of them run. The strictest guidance you will find, that AI should touch Teams only through official enterprise frameworks, is a policy choice for your organization, not a technical requirement of this connection.

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.