Skip to main content
Glama
MartinCley

SharePoint-Cleyrop MCP

by MartinCley
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

SharePoint → Cleyrop MCP

Serveur MCP qui récupère des fichiers depuis SharePoint (via Microsoft Graph, authentification Entra ID déléguée et multi-tenant) et les dépose dans les données de travail d'un projet Cleyrop (via cleyrop-sdk).

Conçu pour un usage multi-organisations en self-service : chaque utilisateur se connecte avec le compte de son organisation et accède au SharePoint de celle-ci, avec ses propres droits. L'isolation par utilisateur se fait via un refresh token propre à chaque personne (variable utilisateur du Tool).

Fonctionnement

SharePoint  ──(Microsoft Graph, token utilisateur Entra ID)──▶  tool MCP
                                                                   │
                                                                   ▼
                                          cleyrop-sdk.upload_file()  ──▶  Données de travail (projet Cleyrop)

Les fichiers transitent par des fichiers temporaires locaux (pas de limite mémoire ; compatible gros fichiers jusqu'à la limite Cleyrop de 5 Go).

Related MCP server: SharePoint MCP Server

Tools exposés

Tool

Rôle

sharepoint_login_start()

Démarrer la connexion (renvoie URL + code)

sharepoint_login_finish(login_id)

Finaliser et obtenir son refresh token

sharepoint_search_sites(query)

Trouver l'identifiant d'un site SharePoint

sharepoint_list_folder(site, path="", drive=None)

Explorer une bibliothèque / un dossier

sharepoint_read_file(site, path, drive=None, max_chars=20000)

Lire le texte d'un fichier (PDF/Word/Excel/texte) sans import

cleyrop_list_projects()

Lister les projets Cleyrop (id / slug)

transfer_sharepoint_to_cleyrop(site, path, project, drive=None, cleyrop_folder=None, recursive=True)

Copier fichier(s) SharePoint → Cleyrop

sharepoint_check_auth()

Vérifier que le refresh token configuré donne accès à SharePoint

sharepoint_debug_headers()

Diagnostic : headers reçus (identifier la variable utilisateur)

site accepte trois formes : un id Graph, un chemin contoso.sharepoint.com:/sites/MonSite, ou une URL complète.

1. Configuration côté Entra ID (à faire par toi)

Une seule application Entra ID, en multi-tenant et client public (device code) : aucun secret client. Chaque utilisateur s'authentifie avec son compte et n'accède qu'à ce qu'il peut déjà voir dans son SharePoint.

  1. Portail Entra ID → Identity → Applications → App registrations → New registration.

    • Name : sharepoint-cleyrop-mcp (au choix).

    • Supported account types : Accounts in any organizational directory (Multitenant) ← important pour le multi-organisations.

    • Redirect URI : laisser vide.

    • → Register. Note l'Application (client) ID.

  2. Authentication → active Allow public client flows = Yes (indispensable pour le device code flow). → Save.

  3. API permissions → Add a permission → Microsoft Graph → Delegated permissions → ajoute :

    • Sites.Read.All

    • Files.Read.All

    • offline_access (indispensable : c'est ce qui délivre le refresh token)

    • User.Read (généralement déjà présent)

    • Grant admin consent pour TON tenant.

  4. Pour la config : ENTRA_CLIENT_ID = Application (client) ID. (ENTRA_TENANT_ID reste à organizations — valeur par défaut multi-tenant.)

Consentement des autres organisations : tu ne peux consentir que pour ton tenant. Pour chaque autre organisation, un admin (ou l'utilisateur) de cette org devra approuver l'application à sa première connexion. Sites.Read.All est souvent « admin-consent required » → certaines orgs demanderont une validation par leur admin. Faire la Publisher verification de l'app réduit la friction du consentement.

2. Configuration côté Cleyrop (à faire par toi)

Le cleyrop-sdk s'authentifie via ClientConfig.from_env() + login_client_credentials(). Tu dois fournir les client credentials de ton service/projet Cleyrop sous forme de variables d'environnement.

Les noms exacts des variables dépendent de ton instance — vérifie-les dans la doc cleyrop-sdk. Renseigne-les dans .env (voir .env.example).

Le package cleyrop-sdk étant privé (registre GitLab), l'installation nécessite UV_INDEX_CLEYROP_SDK_GITLAB_USERNAME / ..._PASSWORD (voir ci-dessous).

3. Installation

cd /home/cleyrop/tool-sharepoint
uv venv && source .venv/bin/activate

# cleyrop-sdk vient d'un registre privé GitLab :
export UV_INDEX_CLEYROP_SDK_GITLAB_USERNAME=...
export UV_INDEX_CLEYROP_SDK_GITLAB_PASSWORD=...

uv pip install -e . \
  --extra-index-url "https://${UV_INDEX_CLEYROP_SDK_GITLAB_USERNAME}:${UV_INDEX_CLEYROP_SDK_GITLAB_PASSWORD}@gitlab.com/api/v4/projects/79823225/packages/pypi/simple"

Copie .env.example → .env et renseigne les variables.

4. Connexion de chaque utilisateur (une fois par personne)

Depuis l'assistant, en langage naturel — l'utilisateur dit simplement « je veux me connecter à SharePoint » et l'assistant enchaîne :

  1. sharepoint_login_start → URL + code à saisir dans le navigateur (connexion avec le compte de l'organisation de l'utilisateur).

  2. L'utilisateur s'authentifie, puis dit « c'est bon ».

  3. sharepoint_login_finish (appelé sans argument — le serveur retrouve la connexion en cours via x-user-id) → la connexion est mémorisée côté serveur pour cet utilisateur. Rien à copier, aucun login_id à fournir : il peut enchaîner directement (recherche de sites, transfert…).

Le token est gardé en mémoire, par utilisateur. Il est donc perdu si le conteneur redémarre : il suffit alors de relancer la connexion. Pour survivre aux redémarrages, l'utilisateur peut (optionnel) coller le token fourni par login_finish dans sa variable utilisateur SHAREPOINT_REFRESH_TOKEN ; le serveur la lit en repli si la mémoire est vide.

Alternative CLI (tests, en DevSpace où cleyrop-sdk est disponible) : ENTRA_CLIENT_ID=<client-id> sharepoint-cleyrop-login.

Le serveur déployé ne fait jamais de connexion interactive « invisible » : il échange silencieusement le refresh token contre des access tokens, par utilisateur.

5. Utilisation en local (client MCP de bureau, stdio)

Pour tester en local sans déploiement :

{
  "mcpServers": {
    "sharepoint-cleyrop": {
      "command": "/home/cleyrop/tool-sharepoint/.venv/bin/sharepoint-cleyrop-mcp",
      "env": {
        "ENTRA_CLIENT_ID": "...",
        "SHAREPOINT_REFRESH_TOKEN": "..."
      }
    }
  }
}

Ce mode utilise le transport stdio. En conteneur / Tool Cleyrop, c'est main.py qui démarre le serveur en HTTP (streamable-http, voir section Build), et SHAREPOINT_REFRESH_TOKEN provient de la variable utilisateur de chaque personne.

Exemple d'usage (depuis un client MCP)

  1. sharepoint_search_sites("marketing") → récupère le site.

  2. sharepoint_list_folder(site, "Documents partages/2026") → repère les fichiers.

  3. cleyrop_list_projects() → récupère l'id/slug du projet.

  4. transfer_sharepoint_to_cleyrop(site, "Documents partages/2026/rapport.pdf", "mon-projet") ou un dossier entier : transfer_sharepoint_to_cleyrop(site, "Documents partages/2026", "mon-projet", cleyrop_folder="sharepoint/2026").

Build de l'image (Docker / La Fabrique)

Le Dockerfile suit la convention des tools MCP Cleyrop : base astral/uv, uv sync, serveur exposé en HTTP (streamable-http) sur le port MCP_PORT (défaut 8000, endpoint /mcp).

cleyrop-sdk (registre GitLab privé) est résolu par uv via l'index cleyrop-sdk-gitlab déclaré dans pyproject.toml. uv s'authentifie tout seul avec les variables UV_INDEX_CLEYROP_SDK_GITLAB_USERNAME / UV_INDEX_CLEYROP_SDK_GITLAB_PASSWORD — injectées par l'environnement de build Cleyrop, donc aucun secret à passer au build.

# build local (hors Cleyrop) : exporter d'abord les credentials du registre
export UV_INDEX_CLEYROP_SDK_GITLAB_USERNAME=...
export UV_INDEX_CLEYROP_SDK_GITLAB_PASSWORD=...
docker build -t sharepoint-cleyrop-mcp .
docker run --rm -p 8000:8000 --env-file .env sharepoint-cleyrop-mcp

Dans La Fabrique : Registre interne → Créer une image → Dépôt interne → dépôt tool-sharepoint, branche v1, chemin du Dockerfile Dockerfile.

Variables d'environnement de l'instance (Cleyrop)

Variable

Portée

Valeur

ENTRA_CLIENT_ID

globale (instance)

Application (client) ID de l'app Entra ID

CLEYROP_DOMAIN

globale (instance)

domaine Cleyrop (cible de l'API données de travail)

MCP_PORT

globale

8000 (= « port exposé » de l'instance)

SHAREPOINT_REFRESH_TOKEN

par utilisateur

refresh token perso (via sharepoint_login_start/finish)

ENTRA_TENANT_ID

globale (option)

organizations par défaut ; un GUID pour restreindre à une seule org

CLEYROP_USER_TOKEN_HEADER

globale (option)

nom exact du header portant le token utilisateur Cleyrop (si la détection auto échoue)

Authentification Cleyrop : l'upload se fait au nom de l'utilisateur, via le token utilisateur transmis par Cleyrop dans un header de la requête (lu automatiquement, comme SHAREPOINT_REFRESH_TOKEN). Le SDK l'utilise comme bearer (ClientConfig.token) — pas besoin de client_secret. Repli possible sur un compte de service (CLEYROP_CLIENT_ID / CLEYROP_CLIENT_SECRET) si aucun token utilisateur n'est disponible.

CLEYROP_DOMAIN est requis pour que le SDK sache quelle API contacter. Si la détection du header de token Cleyrop échoue, l'outil sharepoint_debug_headers liste les headers reçus → fixe alors CLEYROP_USER_TOKEN_HEADER.

Notes & limites

  • Multi-tenant & droits : chaque utilisateur accède au SharePoint de son organisation, avec ses propres droits (flux délégué). L'isolation est assurée par le refresh token personnel — ne jamais mettre SHAREPOINT_REFRESH_TOKEN en variable globale.

  • Variable utilisateur transmise en header : sur Cleyrop, les variables utilisateur arrivent dans les headers de la requête HTTP (et non comme variables d'environnement du process). Le serveur lit donc SHAREPOINT_REFRESH_TOKEN dans les headers (détection tolérante casse/tirets/préfixe). Si le nom de header diffère, le fixer via REFRESH_TOKEN_HEADER. L'outil sharepoint_debug_headers aide à identifier le nom exact.

  • Expiration du refresh token : un refresh token Entra ID est valable ~90 jours en usage glissant. S'il expire (ou en cas de changement de mot de passe / révocation), les tools renvoient une erreur invitant à relancer la connexion.

  • « Token expiré » immédiat = mauvaise valeur, pas une vraie expiration : un refresh token ne peut pas expirer en quelques minutes. Si Entra ID le refuse juste après l'avoir généré, c'est que la variable contient un token d'une connexion précédente (chaque nouvelle connexion invalide les précédentes) ou abîmé au copier-coller (espaces, tirets Unicode). Pour fiabiliser le transport, sharepoint_login_finish renvoie le token encodé en hexadécimal (aucun caractère altérable par le chat) ; le serveur le décode automatiquement. Le tool nettoie aussi espaces et tirets Unicode. Recopie toujours le token du dernier sharepoint_login_finish, et valide avec sharepoint_check_auth.

  • Sécurité : le refresh token vaut accès au SharePoint de l'utilisateur. Il est stocké côté Cleyrop comme variable utilisateur (secret) ; le serveur ne le journalise jamais.

  • Arborescence : un transfert de dossier recrée les sous-dossiers côté Cleyrop (désactivable avec recursive=False).

  • Limite Cleyrop : 5 Go par fichier.

Available Tools

9 tools
cleyrop_list_projectsA

Liste les projets Cleyrop accessibles (id, nom, slug).

Utile pour récupérer l'id ou le slug à passer comme paramètre project de transfer_sharepoint_to_cleyrop.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It indicates that only accessible projects are listed, implying permissions-based filtering. However, it does not disclose behavioral traits like authentication requirements, potential delays, or pagination. Adequate for a simple read-only list, but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two concise sentences with no waste. It is front-loaded with the primary action and immediately explains the utility.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with no parameters and an output schema (as indicated by context). The description covers what it returns and its purpose. Minor gaps exist, such as whether the list is paginated or sorted, but overall it is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the baseline is 4. The description adds no parameter information, but none is needed. Schema coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool lists accessible Cleyrop projects with id, name, slug. It provides the specific verb 'Liste' and resource 'projets Cleyrop', and distinguishes from siblings by being the only project listing tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the usage: to retrieve the id or slug for the `transfer_sharepoint_to_cleyrop` parameter. It provides clear context but does not include when-not-to-use or alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sharepoint_check_authA

Vérifie que le refresh token configuré donne bien accès à SharePoint.

À utiliser pour diagnostiquer un problème d'authentification sans lancer un transfert : lit SHAREPOINT_REFRESH_TOKEN et tente d'obtenir un access token Entra ID. Remonte l'erreur exacte si le token est refusé.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It transparently details that the tool reads the SHAREPOINT_REFRESH_TOKEN variable, attempts to obtain an Entra ID access token, and returns the exact error if refused. It also clarifies it does not launch a transfer, making behavior clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, concise and front-loaded. The first sentence states the purpose, the second adds context and detail. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an existing output schema (context signals indicate its presence), the description is complete. It explains the tool's function, input (env variable), and behavior on error. No further detail needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so baseline 4 applies. The description correctly adds no parameter info, as none are needed. Schema coverage is 100% by default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool verifies that a configured refresh token gives access to SharePoint. It uses specific verbs ('vérifie') and distinguishes from siblings like sharepoint_login_start/finish and transfer tools by noting it's for diagnosing auth problems without launching a transfer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly indicates when to use the tool ('pour diagnostiquer un problème d'authentification sans lancer un transfert'). It provides context but does not explicitly mention alternatives or exclusions, though the context implies it's for pre-checks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sharepoint_debug_headersA

Diagnostic : liste les en-têtes de la requête courante (valeurs masquées).

Sert à identifier comment Cleyrop transmet la variable utilisateur SHAREPOINT_REFRESH_TOKEN (nom exact du header). Aucune valeur n'est révélée en clair.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description alone must convey behavioral traits. It explicitly states values are masked and no plain text is revealed, which is key for a debug tool that handles sensitive data. It also implies read-only diagnostics. It does not mention any side effects or authentication requirements, but for this simple tool, the disclosure is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences. The first sentence states the action, and the second adds the purpose and constraint (masked values). No unnecessary words. It's front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, read-only diagnostic), the description is complete. It covers the what, why, and a key behavioral constraint (masked values). An output schema exists, so return values are covered there. The tool's context within the sibling set is clear (debugging authentication headers).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameters, and it correctly omits any. The baseline score of 4 is appropriate as the description adds no extra parameter detail, which is fine.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists headers of the current request (values masked), which is a specific and unambiguous purpose. It uses the verb 'lists' and the resource 'headers', making it distinct from sibling tools like sharepoint_login_start or sharepoint_read_file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies a concrete use case: identifying how Cleyrop transmits the SHAREPOINT_REFRESH_TOKEN header. This gives guidance on when to use the tool. However, it does not explicitly mention when not to use it or compare it to sibling tools, so it's slightly lacking in full usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sharepoint_list_folderB

Liste le contenu d'un dossier d'une bibliothèque SharePoint.

ParametersJSON Schema
NameRequiredDescriptionDefault
siteYesidentifiant du site. Accepte un id Graph, un chemin `contoso.sharepoint.com:/sites/MonSite`, ou une URL complète.
pathNochemin relatif à la racine de la bibliothèque (ex. "Documents partages/2026"). Vide = racine.
driveNonom ou id de la bibliothèque de documents. Vide = bibliothèque par défaut ("Documents").

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description bears full responsibility. It only states the basic purpose and does not disclose behaviors such as recursion depth, pagination, error handling, or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short sentence with no unnecessary words. It is front-loaded and conveys the core purpose efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description is too minimal. It does not explain what the output contains (e.g., list of files? subfolders? metadata?) or behavior nuances like depth or sorting. More context is needed for a listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the parameter descriptions are detailed (e.g., site accepts IDs, paths, URLs). The tool description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Liste' and the resource 'contenu d'un dossier d'une bibliothèque SharePoint'. It distinguishes from siblings like sharepoint_read_file (reads a file) and sharepoint_search_sites (searches sites).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool or when not to. There are no exclusions or alternatives mentioned, leaving the agent without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sharepoint_login_finishA

Finalise la connexion SharePoint et mémorise l'accès de l'utilisateur.

APPELLE CET OUTIL SANS AUCUN ARGUMENT dès que l'utilisateur indique qu'il a terminé l'étape navigateur — par exemple « c'est bon », « j'ai validé », « connecté », « go ». Le serveur retrouve automatiquement la connexion en cours grâce à l'identité de l'utilisateur. Ne demande JAMAIS de login_id à l'utilisateur : laisse le paramètre vide (il n'est utile qu'en mode local sans identité).

En cas de succès, le refresh token est mémorisé côté serveur pour l'utilisateur courant : il n'a en principe rien à copier, il peut enchaîner directement (recherche de sites, transfert...).

ParametersJSON Schema
NameRequiredDescriptionDefault
login_idNooptionnel — ne le renseigner qu'en mode local (stdio).

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that refresh token is stored server-side, user need not copy anything, and connection is auto-retrieved by identity. No annotations provided, so description carries full burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with main purpose first, then imperative instructions. Slightly verbose but clear and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers usage, success behavior, side effects (token storage), and mentions output schema exists. Adequate for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Explains login_id is optional and only for local mode, adding meaning beyond schema's description. Agent knows not to request it from user.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool finalizes SharePoint login and memorizes user access, distinguishing it from siblings like sharepoint_login_start.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call without arguments after user completes browser step, and warns not to ask for login_id. Provides clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sharepoint_login_startA

Démarre la connexion / l'authentification de l'utilisateur à SharePoint.

APPELLE CET OUTIL DIRECTEMENT dès que l'utilisateur exprime l'intention de se connecter à SharePoint — par exemple « je veux me connecter à SharePoint », « connecte-moi à SharePoint », « authentifie-moi », « login SharePoint ». Ne te contente pas d'expliquer la marche à suivre et ne demande pas à l'utilisateur d'appeler une fonction : lance directement cet outil.

Renvoie une URL et un code à saisir dans le navigateur (connexion avec le compte de l'organisation de l'utilisateur), ainsi qu'un login_id. Quand l'utilisateur indique ensuite qu'il a terminé dans le navigateur, appelle sharepoint_login_finish avec ce login_id.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description fully discloses behavior: returns a URL, code, and login_id; instructs user to enter code in browser; and directs to call 'sharepoint_login_finish' with the login_id afterward.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is about 6 sentences, clear and front-loaded with purpose. Slightly verbose with repeated examples but well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an output schema (presumably defined), the description covers the login flow, return values, and necessary next step (calling sharepoint_login_finish). No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so no parameter info is needed. The description adds no param details, which is acceptable. Baseline 4 for no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: starting login/authentication to SharePoint ('Démarre la connexion / l'authentification'). It distinguishes itself from sibling 'sharepoint_login_finish' which is for completing the login.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use instructions: call directly upon user intent to log in, with examples. It tells not to explain steps or ask user to call function. However, it does not mention alternatives like checking auth status first via 'sharepoint_check_auth'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sharepoint_read_fileA

Lit un fichier SharePoint et renvoie son texte, sans l'importer dans Cleyrop.

À utiliser quand l'utilisateur veut analyser, résumer, interroger un document SharePoint directement (sans le transférer au préalable dans les données de travail). Formats supportés : PDF, Word (.docx), Excel (.xlsx), et texte (txt, csv, md, json, html, xml...). Pour copier durablement le fichier dans un projet, utiliser plutôt transfer_sharepoint_to_cleyrop.

ParametersJSON Schema
NameRequiredDescriptionDefault
siteYesidentifiant du site (id Graph, chemin `hôte:/sites/X`, ou URL).
pathYeschemin du fichier (relatif à la racine de la bibliothèque).
driveNobibliothèque source (vide = bibliothèque par défaut).
max_charsNonombre max de caractères renvoyés (tronqué au-delà).

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses read-only nature (no import), supported formats, and truncation behavior (max_chars). With no annotations, it carries the full burden well, though could mention authentication or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, no fluff. Front-loaded with core action, then use case, formats, and alternative. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers key aspects: action, use case, alternative tool, supported formats, truncation. Lacks mention of error handling or permissions, but given output schema exists, it's reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. Description adds minor context about path relativity and max_chars truncation, but does not significantly enhance beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'lit' (reads) and resource 'fichier SharePoint', explicitly states it does not import into Cleyrop, distinguishing it from sibling tool transfer_sharepoint_to_cleyrop.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (for analysis, summarization, querying directly) and when not to (for permanent copying, use transfer_sharepoint_to_cleyrop).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sharepoint_search_sitesA

Recherche des sites SharePoint par mot-clé.

Renvoie pour chaque site son nom et son identifiant (à passer ensuite comme paramètre site des autres tools). Utile quand on ne connaît pas l'URL exacte du site.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesmot-clé recherché dans les noms/URL de sites.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It only states the search action and return fields, but omits details like case sensitivity, result limits, pagination, or whether the search is read-only (though likely safe). Minimal transparency beyond the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. Purpose is front-loaded, and the second sentence adds usage guidance. Concise and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter search tool with an output schema (mentioned in context), the description covers the main purpose, return structure, and usage context. Minor missing details like search behavior or sorting, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (the single 'query' parameter has a description identical to the tool description). The description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's verb ('Recherche') and resource ('sites SharePoint par mot-clé'), and specifies what it returns (name and ID). It distinguishes itself from sibling tools that handle folders, files, or authentication.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage scenario: 'Utile quand on ne connaît pas l'URL exacte du site.' It implies when to use (when URL unknown), but does not explicitly exclude alternatives or state when not to use. Still, it offers helpful context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

transfer_sharepoint_to_cleyropA

Copie un fichier ou un dossier SharePoint vers les données de travail d'un projet Cleyrop.

Le contenu est téléchargé depuis SharePoint (Microsoft Graph) puis ré-uploadé via le cleyrop-sdk. Les fichiers transitent par des fichiers temporaires (supporte les gros fichiers, pas de limite mémoire).

ParametersJSON Schema
NameRequiredDescriptionDefault
siteYesidentifiant du site SharePoint (id, chemin ou URL — voir `sharepoint_list_folder`).
pathYeschemin du fichier OU du dossier à transférer, relatif à la racine de la bibliothèque.
projectYesid ou slug du projet Cleyrop de destination.
driveNobibliothèque SharePoint source (vide = "Documents").
cleyrop_folderNodossier de destination dans les données de travail (créé si absent). Vide = racine du projet.
recursiveNosi `path` est un dossier, transférer aussi les sous-dossiers.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description effectively discloses key behavioral traits: the process involves downloading from SharePoint and re-uploading via SDK, uses temporary files, and handles large files without memory limits. It does not mention authentication or error handling, but given no annotations, this is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise: two sentences clearly state purpose and mechanism without extraneous words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters (3 required) and an output schema, the description covers the core process and critical behavior (temp files, large file support). Minor gaps exist (conflict handling), but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it repeats defaults but does not clarify parameter interplay or format details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the action ('copie un fichier ou un dossier') and the source/destination (SharePoint to Cleyrop). It clearly differentiates from sibling tools like sharepoint_read_file (read-only) and sharepoint_list_folder (listing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for transferring files/folders but does not explicitly state when to use this tool versus alternatives like sharepoint_read_file. No direct guidance on prerequisites or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 9 tool updatesv0.1.0
    • First observedcleyrop_list_projects
    • First observedsharepoint_check_auth
    • First observedsharepoint_debug_headers
    • First observedsharepoint_list_folder
    • First observedsharepoint_login_finish
    • First observedsharepoint_login_start
    • First observedsharepoint_read_file
    • First observedsharepoint_search_sites
    • First observedtransfer_sharepoint_to_cleyrop
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct action: authentication flow (start/finish), diagnostics (check_auth, debug_headers), browsing (list_folder, search_sites, list_projects), reading files, and transferring. No two tools have overlapping purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., sharepoint_list_folder, sharepoint_login_start, cleyrop_list_projects) with snake_case and clear prefixes for SharePoint vs Cleyrop. No mixing of conventions.

Tool Count5/5

With 9 tools covering authentication, browsing, reading, and transfer, the count is well-scoped for the integration domain. Each tool serves a clear need without excess or deficiency.

Completeness4/5

The surface covers the primary workflow (authenticate, browse, search, read, and transfer from SharePoint to Cleyrop). Minor gaps exist, such as no write operations to SharePoint (e.g., upload or delete), but these are outside the core purpose.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • SharePoint MCP Server

    ezemriv
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables interaction with Microsoft SharePoint sites, document libraries, and files through the Microsoft Graph API. Supports browsing, searching, uploading/downloading files, managing lists, and creating sharing links with secure OAuth authentication.
    2
    MIT

  • sharepoint-mcp

    LesterAJohn
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables reading and searching Microsoft SharePoint content via the Graph API, including sites, document libraries, folders, and files. Also provides admin tools for configuration and token management.
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MartinCley/Sharepoint-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server