How to connect SharePoint 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 SharePoint from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

SharePoint 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 SharePoint 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.

Search results answer this with app-registration surgery: add Sites.Read.All in Entra ID, grant admin consent, check the token in jwt.ms, look at Site.Selected assignments. None of that applies to a delegated hosted connection, where the permissions were fixed at sign-in and there is no token for you to inspect. Two things cause it here instead. The first is genuine access: the connection acts as you, so a site or library your account cannot open returns 403, and it will keep doing so until someone shares it with you. Open the site in a browser as the same account to confirm in ten seconds. The second is a placeholder argument: an agent that has not listed anything yet invents a site id or list guid, and because those are structurally valid the call reaches Microsoft and comes back as a permissions failure rather than a bad id. Run share_point_list_sites and share_point_list_all_lists first, then retry with real values.

Ask the agent to diagnose it:

Run share_point_get_current_user and tell me which account is connected. Then run share_point_list_sites and show me every site you can see. Do not retry the failing call until both have returned.

This is unique permissions, and it is a SharePoint feature rather than a fault. Any site, library, folder, or single item can have its permission inheritance broken, so a person with access to the parent has none to the child. The agent hits exactly the same wall you would. share_point_get_user_effective_permissions_on_web reports what the connected account actually holds on a given web, which turns a guessing game into one call. If the answer is that you genuinely lack access, the fix is a person who owns that site granting it, and no amount of reconnecting will substitute.

Ask the agent to diagnose it:

Run share_point_get_user_effective_permissions_on_web for the site I name and tell me exactly which permissions the connected account has there.

If the name looks right, the tool catalog had not loaded when the first call went out; schemas load on demand, so retrying once usually clears it. The more interesting failure is an argument that does not exist. share_point_list_drives_rest_api takes no site_id, so an agent that helpfully collected a site GUID from share_point_list_sites and passed it in gets an error that reads like a permissions or not-found problem. Tell the agent to call the tool with the arguments its schema actually declares. This is a different failure from what most search results describe, which is a local MCP server missing from an editor config; there is no local server here.

Ask the agent to diagnose it:

List the SharePoint tools you have available and show me the exact arguments the one you just called accepts. Then call it again with only those arguments.

Try reconnecting SharePoint 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 SharePoint: link your SharePoint account once in the browser and Hermes Agent can call the SharePoint API through 86 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 SharePoint 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 SharePoint 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 SharePoint working from chat.

Yes. Registering an app is what you do when you are building the integration: create the application in Entra ID, choose delegated or application permissions, get admin consent for the tenant, then manage a secret that expires on a schedule. ClawLink connects through an application that is already registered, so your side of it is a Microsoft sign-in. What you are approving is delegated access, meaning the connection acts as you rather than as a service with tenant-wide reach. Your administrator can still see and revoke the grant from the tenant's enterprise applications, and depending on how your tenant is configured they may need to approve it once before the connection completes.

No, and the mechanism is worth understanding because it is the opposite of how the app-registration route usually works. A registered app with application permissions and admin consent can be granted tenant-wide reach across every site. This connection uses delegated access instead, so the ceiling is your own account. Sites you cannot open, you cannot reach through the agent. Libraries with unique permissions that exclude you stay excluded. If you want to know exactly what the agent can see before you trust it with anything, ask it to run share_point_list_sites and read the list back.

Not to use it. You need whatever access you already have to the sites you want the agent to work with. Whether you need an administrator involved at all depends on your tenant's consent policy: many organizations allow users to consent to applications themselves, and others route every new application to an admin approval queue. If your sign-in ends on a screen saying approval is required, that is the tenant policy rather than a ClawLink setting, and the fix is your IT team approving the application once for everyone.

No. The connection targets SharePoint Online in Microsoft 365. An on-premises SharePoint Server farm is not reachable through this flow, and the community MCP servers that do target it need credentials you manage and a network path to the farm.

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.