AI and agents
AI and agents on SharePoint data
Most teams arrive here after an agent has hit a wall on a SharePoint list. A Copilot Studio agent answers from the first 2,048 rows of a big list, or the admin will not approve a Graph app registration for a bot that only needs to read. Ask enough questions in a row and SharePoint starts throttling the agent as well.
SPSync keeps a copy of the list in a database you run. The agent reads that copy with a database login and holds no Graph permission of its own, so a second agent, or a fifth, changes nothing on the SharePoint side.
SharePoint item permissions are not copied into the replica. The database role you
grant each agent decides what it can see, with row-level security where one table
holds rows it should not read. SPSync ships no agent of its own. To ask questions
of the data, point the Postgres or SQL Server MCP server you already run, or your
own SQL tool, at the replica. Or run spsync mcp serve, a read-only MCP
server over one replication that knows each list's SharePoint columns, lookups and
choice values.
A second MCP server works on SPSync itself. It lets an assistant such as Claude Code set up and run your replications, and the section below describes what it can and cannot do.
Book a call to talk through your use case, see further walkthroughs or demos, and set up a trial in your own environment.
For whoever sets SPSync up
Let an AI assistant set SPSync up
The admin MCP server is part of the SPSync server and the desktop app. An assistant connected to it can read how SPSync is set up. With a token that allows changes, it can also create the connection, the destination and the replication, start a run, and read why a run failed. It works on SPSync's configuration only. It never reads the rows in your replica, and the data server above never changes the configuration, so a token for one cannot do the other's job.
What you can ask for
Say what you want in plain words, such as copying the Projects list from the Finance site into your Postgres every five minutes. The assistant starts by reading what already exists. Five guided prompts cover the common jobs.
- Set up a first replication, from sign-in to the first run.
- Enable unattended sync, which needs a tenant admin's consent and a grant on each site.
- Bring your own app registration.
- Troubleshoot the last run.
- Connect a second tenant.
Which assistants it connects to
Set-up is documented for Claude Code, Claude Desktop, Cursor, VS Code and Copilot
Studio. Claude Code, Cursor and VS Code connect to the server's /mcp
address with a token sent as a bearer header. Claude Desktop starts a small
command, spsync mcp admin, which finds the running desktop app and
passes the conversation on. That command is part of SPSync's
command-line tool, which is a separate install from
the desktop app, so Claude Desktop needs the command-line tool installed. Copilot Studio takes the token as an API key and
needs your server reachable at a public https address.
In the app, open Settings and choose Connect an AI assistant. It creates a token and shows the configuration to paste for Claude Desktop, Claude Code, Cursor and Copilot Studio, and the address and header for any other client, VS Code included. With the command-line tool installed and the desktop app open, Claude Code needs one line.
claude mcp add spsync -- spsync mcp adminClaude.ai and ChatGPT custom connectors are not supported today. They need a sign-in flow the admin server does not have, and the roadmap lists it.
Bring your own app registration
If your tenant wants its own Entra app registration for SPSync, the assistant helps and you keep a manual route. It can ask you for a second sign-in and create the registration through Microsoft Graph, then check the credential once you have entered it. That consent request has not been run against a real tenant, so treat the manual route as the dependable one. The assistant can print what the registration needs, with the Azure CLI and PowerShell commands, and your own admin runs them. It falls back to the same list when your tenant does not let people register apps.
How secrets and changes are kept safe
The design treats the assistant as helpful and fallible, and the conversation as the wrong place for a secret. When a connection string, client secret or API key is needed, the assistant gives you a link where you type the value yourself. The link works once, expires after fifteen minutes and is tied to the token that asked, one record and one field. No tool takes a secret as an argument, and no tool returns one.
Each assistant gets its own token with a name, an access level of read or manage,
and an expiry of 90 days unless you pick another. SPSync shows it once and keeps
only a hash. The token is accepted on the /mcp address and nowhere
else. The server checks the access level before a tool runs, so a read token
cannot call a tool that changes anything. A revoked or expired token is refused on
its next request.
A person stays in the loop for the steps that need one. Sign-in is a device code you enter yourself. A tenant admin's consent and the grant on a site go to the people who can give them, as a link, a draft message or the PowerShell to run. Deleting a connection, a destination or a replication shows a preview first and needs a confirmation the server checks. Replacing a stored credential works the same way.
Every tool call an assistant makes is recorded with the token's name, the client name and version, the tool, the arguments with anything secret-shaped removed, the outcome and the time it took. The Activity screen lists these rows beside sync runs, under an AI assistants filter, and each token is rate limited. The security page says the same in its own words.
For developers
Agents and SQL tools over SharePoint lists
If you are building the agent yourself, the replica gives it tables to query where it used to walk list pages. A lookup arrives as a key column and a multi-value column as a child table, so a question that spans two lists becomes a join.
One SQL copy for every agent
SPSync makes every Graph call, and each agent you add gets only a database login to the same copy.
SQL tools for an agent
Hand the agent a read-only SQL tool over the replica, so it has no SharePoint permission to misuse and no list to overload.
Chat with your SharePoint data
People ask in plain English and a text-to-SQL tool answers from the typed tables in the replica.
Retrieval over list items
The sync writes the embeddings into pgvector or Azure AI Search, so retrieval reads vectors refreshed on every run.
Semantic search on free text
Search a comments or description column by meaning once its text is embedded alongside the row in Postgres.
Training and evaluation sets
Build a training set from typed tables in place of a Graph export you clean and retype before every project.
For Copilot Studio makers
Grounding Copilot Studio on SharePoint data
Copilot Studio accepts a SharePoint list as knowledge, and Microsoft's quotas page (checked 20 October 2026) says list queries only return data from the first 2,048 rows. Past that size the answers come from a slice of the list, and nothing in the reply says so. Grounding the agent on the SQL copy puts every row behind its answers, either through Azure SQL in what Microsoft calls real-time knowledge connectors (a preview feature) or through a read-only SQL tool.
Copilot Studio grounding
Where a list added as knowledge runs short, what the Power Automate workaround costs, and the two ways to put the replica in front of an agent.
Search index over list data
An Azure AI Search, Elasticsearch or OpenSearch index filled from your lists and updated by each delta.
Library metadata for AI
Library columns kept in SQL as a catalogue the agent filters before it fetches a document, while the files themselves stay in SharePoint.
For security leads
What an agent can see and how you audit it
You set an agent's reach in the database. Give each agent its own login with
SELECT on the tables or views its job needs, and add row-level security when it
should see only some of the rows. To record what it queried, use the database's
own logging, which means pgAudit or log_statement on Postgres and a
database audit specification on SQL Server. SPSync reads SharePoint and never
writes to it.
Security overview
Read-only access to SharePoint, app permissions granted per site with Sites.Selected, and where the replicated content is kept.
Admin permissions pack
The Graph permissions SPSync asks for, the consent flow and the commands an admin runs to grant them site by site.
Controlling what an agent reads
A login per agent, a Postgres policy that limits one agent to one region, and the audit settings for Postgres, SQL Server and Azure SQL.
Write-back
Writing back to SharePoint from an agent
SPSync has no code path that writes to SharePoint today. An agent that wants to change an item can insert a proposal into a staging table you create, a person makes the approved change in the list, and the next sync brings the edit into the replica. Write-back from SPSync itself is designed around changes a person approves, and it has not shipped.
Two-way sync design
How approved write-back is designed, with a per-list opt-in, an etag check on each change, and SharePoint winning any conflict.
SharePoint and PostgreSQL two-way sync
Most two-way requests are a heavy read and a light write, and this page shows how the read works today and how the write is designed.
Vector destinations
Vector search on SharePoint data with pgvector or Azure AI Search
Postgres with pgvector and Azure AI Search receive an embedding for each row, generated during the sync from OpenAI, Azure OpenAI or a local model that needs no API key. Only rows whose text changed are embedded again. Elasticsearch, OpenSearch, LanceDB, Qdrant and Weaviate receive the same columns with no vector.
Compare
SPSync compared with Stacksync for agents
Stacksync makes a good case for one synced Postgres behind every agent, and we agree with it. The comparison looks at what that case means when the source is SharePoint.
Articles
Articles on AI and search over SharePoint
The articles take one problem at a time, from a count that comes out wrong to an embedding index that has gone stale. They are also collected on the blog under All AI and search articles.
- Why Copilot cannot count the rows in your SharePoint list
Copilot Studio reads the first 2,048 rows of a list and counts what search returns. Here are the documented limits and what a SQL replica changes.
- Four ways to embed SharePoint list text, compared
A facilities incident list embedded four ways, from a Power Automate flow to embedding on sync into pgvector, with the upkeep each one brings.
- An MCP server for SharePoint data that queries SQL
Claude, ChatGPT or Cursor reading a read-only SQL replica of SharePoint lists through a database MCP server, with no Graph permission of its own.
- Text-to-SQL on SharePoint data depends on the schema
A project office asked a chat box which clients had projects at risk and got ids and claims strings back. The schema fixes that make the SQL right.
- Running a local AI model over SharePoint data in DuckDB
A law firm that cannot send client data to a public AI service replicates its Matters list into DuckDB on a laptop and queries it with Ollama.
- Keeping a SharePoint vector index current as items change
An HR assistant kept quoting a carry-over rule that changed in March. The four kinds of embedding drift, and re-embedding only rows that changed.
- Read SharePoint once and let the AI pipeline query the copy
A finance assistant hit 429s every month-end. The resource-unit arithmetic behind Graph throttling, and how one delta reader and a replica fix it.
- Library metadata is the catalogue an AI assistant needs
A policy assistant quoted a withdrawn document because it only read file text. A replicated metadata table lets it pick documents by status first.
- Training and evaluation sets from SharePoint records
A service desk scores a ticket-type assistant against three years of SharePoint tickets, with SQL over a replica and snapshots that can be rebuilt.
- Copilot Studio and SharePoint lists: four routes compared
A Copilot Studio maker with a 9,000-item list has four ways to answer from it. What list knowledge, a flow, Dataverse and a SQL replica each cost.
- Agents on SharePoint data without a Graph app registration
Your request for a Graph app registration for an AI loader was refused. One read-only Sites.Selected grant to a replica, then a database role per tool, is easier to approve.
- One SQL copy of SharePoint for every agent you run
What a cross-list question costs an AI agent through Graph, worked for three real-sized lists, and the same question as one SQL join on a replica.
- Why your agent should not query SharePoint live
Agent tools that call Microsoft Graph share SharePoint's throttling budgets with every other integration. When a live read is right, and when to use a replica.
- Supabase and SharePoint lists for an app and an AI agent
A field-ops app on Supabase and an AI agent reading the same replicated SharePoint lists, with row-level security per team and a read-only role for the agent.
- Human-in-the-loop AI agents over SharePoint evidence
An agent checks contractor certificates for each job against a SQL replica of SharePoint, writes the gaps to a review table, and a person approves the packet.
- Copilot Studio says it cannot find the item at row 3,000
Your agent answers about some list items and says others do not exist. The 2,048-row read and search ranking explain it, with a test to show what it sees.
- Azure AI Foundry agents and SharePoint list rows
The Foundry SharePoint tool (preview) retrieves text from documents, not list rows. What each Foundry tool reads today, and how to query a list replica.
- SharePoint lists in Foundry IQ after On Your Data retired
Azure OpenAI On Your Data retired on 14 October 2026. How to ground answers on a SharePoint list in Foundry IQ, through an Azure AI Search index kept current.
- Keeping SharePoint data in region for AI: where prompts, embeddings and indexes go
Your data protection officer asks whether AI on a SharePoint list sends it abroad. Four hops decide it: the model, the embedding call, the index and the logs.
Guides
Guides for architects and search designers
AI on SharePoint data architecture guide
When an agent should query SQL and when it should search embeddings, and what the replica leaves out.
Designing a search index from SharePoint lists
The index shapes SPSync builds in Azure AI Search and pgvector, which text gets embedded, and how to bound who can query the index.
Talk it through against your own lists
Bring the list your agent struggles with. On a call we can run SPSync against your own tenant and talk through the login and the policy your agent would need.
Book a call to talk through your use case, see further walkthroughs or demos, and set up a trial in your own environment.