What can you do with this server?

This is a read-only MCP server that gives AI assistants access to Gilbert meeting data, including transcriptions and summaries. * List meetings: Browse meetings with pagination and filters by status (pending, processing, completed, error) and creation date range. * Get meeting details: Retrieve complete information about a specific meeting, including metadata, full transcription, and summary. * Get transcript: Fetch just the plain text transcription of a meeting, formatted as Speaker 0: ... Speaker 1: ... * Get summary: Retrieve just the markdown summary/synthesis of a meeting. * Search meetings: Full-text search across meeting titles, transcriptions, and summaries — useful for finding meetings where a specific topic was discussed. * List folders: View folders and their meeting counts. * Get folder meetings: Retrieve meetings within a specific folder, including subfolders. Access to shared content (meetings/folders from other users) is available if the API key has the shared:read scope.

gilbert-mcp

by HugoF1234

Overview Schema Related Servers Score Discussions

JavaScript

Remote

gilbert-mcp

npm License: MIT

Serveur Model Context Protocol (MCP) officiel de Gilbert.

Permet à Claude Desktop, Claude Code, Cursor, VS Code, Zed, Continue et tous les clients compatibles MCP d'accéder aux réunions, transcriptions et synthèses Gilbert d'un utilisateur — en lecture seule.

Installation rapide

Toutes les configs partagent la même commande : npx -y gilbert-mcp avec la variable GILBERT_API_KEY.

Claude Desktop

Éditez le fichier de configuration :

macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
Windows : %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "gilbert": {
      "command": "npx",
      "args": ["-y", "gilbert-mcp"],
      "env": {
        "GILBERT_API_KEY": "glbrt_live_XXXXXXXXXXXXXXXXXXXXXXXX"
      }
    }
  }
}

Redémarrez Claude Desktop. Vous pouvez maintenant demander :

« Liste mes réunions terminées cette semaine » « Résume-moi la réunion du 12 avril » « Trouve-moi la réunion où on a parlé de budget Q3 »

Claude Code

claude mcp add gilbert --env GILBERT_API_KEY=glbrt_live_XXX -- npx -y gilbert-mcp

Cursor

Settings > Features > Model Context Protocol > Add MCP Server :

{
  "name": "gilbert",
  "command": "npx",
  "args": ["-y", "gilbert-mcp"],
  "env": { "GILBERT_API_KEY": "glbrt_live_XXXXXXXXXXXXXXXXXXXXXXXX" }
}

VS Code

.vscode/mcp.json (ou la commande MCP: Add Server) :

{
  "servers": {
    "gilbert": {
      "command": "npx",
      "args": ["-y", "gilbert-mcp"],
      "env": { "GILBERT_API_KEY": "glbrt_live_XXXXXXXXXXXXXXXXXXXXXXXX" }
    }
  }
}

Zed

Dans settings.json, sous context_servers :

{
  "context_servers": {
    "gilbert": {
      "command": { "path": "npx", "args": ["-y", "gilbert-mcp"], "env": { "GILBERT_API_KEY": "glbrt_live_XXX" } }
    }
  }
}

Docker (alternative)

docker build -t gilbert-mcp .
docker run --rm -i -e GILBERT_API_KEY=glbrt_live_XXX gilbert-mcp

Related MCP server: migas-mcp

Obtenir une clé API

Contactez votre administrateur Gilbert pour qu'il génère une clé depuis la console admin. Scope minimum requis : meetings:read (lecture seule).

Tools exposés

Tous les tools sont en lecture seule (readOnlyHint).

Tool	Description
`list_meetings`	Liste paginée, filtres par statut/date
`get_meeting`	Détail complet d'une réunion (metadata + transcription + synthèse)
`get_transcript`	Transcription texte seule
`get_summary`	Synthèse markdown seule
`search_meetings`	Recherche full-text
`list_folders`	Liste les dossiers (nom + nombre de réunions)
`get_folder_meetings`	Réunions d'un dossier (et sous-dossiers)

Le contenu partagé avec l'utilisateur (réunions/dossiers d'autres personnes) n'est accessible que si la clé API porte le scope shared:read. Par défaut, une clé ne voit que le contenu de son propriétaire.

Variables d'environnement

GILBERT_API_KEY (requis) : clé au format glbrt_live_...
GILBERT_BASE_URL (optionnel) : défaut https://gilbert-assistant.ovh/api/v1

Confidentialité & sécurité

Ce serveur expose des transcriptions et synthèses de réunions (données potentiellement sensibles). Il s'exécute localement en stdio, n'ouvre aucun port entrant, ne journalise jamais la clé API et n'écrit aucune donnée de réunion sur disque. Voir SECURITY.md.

Développement

git clone https://github.com/HugoF1234/Gilbert-mcp
cd Gilbert-mcp
npm install
GILBERT_API_KEY=glbrt_live_... npm run dev   # stdio
npm test                                     # build + smoke test (handshake MCP)

Voir CONTRIBUTING.md pour le process de release et docs/SUBMISSION.md pour le référencement dans les catalogues.

Licence

Support

Documentation API : https://gilbert-assistant.ovh/api/v1/docs
Contact : contact@lexiapro.fr

Available Tools

5 tools

get_meetingDétail d'une réunionA

Read-only

Récupère le détail complet d'une réunion : metadata + transcription + synthèse. Utile quand l'utilisateur veut résumer une réunion spécifique.

ParametersJSON Schema

Name	Required	Description	Default
`meeting_id`	Yes	UUID de la réunion

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, ensuring the agent knows this is a safe, read-only operation that may return open-ended data. The description does not add further behavioral details beyond what annotations provide, nor does it contradict them.

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?

Two concise sentences, front-loaded with the core action. Every word serves a purpose with no fluff. Structure is efficient and easy to parse.

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 1-param retrieval tool with no output schema, the description adequately explains what is returned (metadata+transcription+synthesis) and a use case. It is almost complete, though explicitly stating the return format would push it to perfect completeness.

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?

The only parameter (meeting_id) is fully described in the input schema (UUID format, required). Schema coverage is 100%, so the description adds no additional semantic value beyond the schema, resulting in a baseline score.

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 what the tool does: retrieve full meeting details including metadata, transcription, and synthesis. It also provides a concrete usage example (summarizing a specific meeting), distinguishing it from siblings like get_summary or get_transcript.

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 when the user wants to summarize a meeting, but does not explicitly state when not to use it or mention alternatives among siblings. While the context makes it somewhat clear, explicit guidance would improve this dimension.

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

get_summarySynthèse d'une réunionA

Read-only

Récupère la synthèse markdown d'une réunion (plus léger que get_meeting).

ParametersJSON Schema

Name	Required	Description	Default
`meeting_id`	Yes	UUID de la réunion

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint. The description adds that the output is a markdown summary and that it's lighter, which provides useful behavioral context beyond annotations.

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?

Single sentence, no wasted words, concise and to the point.

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?

Without an output schema, the description clarifies the return format (markdown summary) and provides sibling comparison. For a simple single-parameter tool, it is fairly complete, though more detail about the summary content could be added.

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% with the single parameter meeting_id described in the schema. The description does not add any additional semantic detail about the parameter beyond what is already in the 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?

Clearly states it retrieves the markdown summary of a meeting and explicitly distinguishes from get_meeting by being lighter, which helps the agent differentiate between sibling tools.

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?

Provides clear context by noting it's lighter than get_meeting, implying use when a full meeting object is not needed. However, it does not explicitly state when not to use or mention alternatives beyond get_meeting.

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

get_transcriptTranscription d'une réunionA

Read-only

Récupère uniquement la transcription texte d'une réunion (plus léger que get_meeting). Format « Speaker 0: ...\nSpeaker 1: ... ».

ParametersJSON Schema

Name	Required	Description	Default
`meeting_id`	Yes	UUID de la réunion

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint. The description adds no behavioral disclosures beyond the format of the transcription. While consistent, it does not provide additional context like authorization needs or termination conditions. With annotations covering the safety profile, a score of 3 is appropriate.

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 sentence followed by a format example. It is concise, front-loaded with the purpose, and contains no extraneous information. Every element adds value.

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?

For a simple tool with one parameter and no output schema, the description adequately explains what it does, how output is formatted, and how it differs from a sibling. The information is sufficient for an agent to decide when and how to use it.

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% with one parameter 'meeting_id' described as 'UUID de la réunion' in the schema. The tool description does not add extra parameter-level information. Baseline 3 is correct as the schema does the heavy lifting.

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 retrieves the text transcription of a meeting, distinguishes it from get_meeting by noting it's lighter, and specifies the output format. The verb 'récupère' and resource 'transcription texte d'une réunion' are specific and unambiguous.

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 clear context by comparing to get_meeting (lighter), implying when to use this tool over alternatives. However, it does not explicitly state when not to use it or list exclusions. It gives good guidance but lacks explicit boundaries.

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

list_meetingsLister les réunionsA

Read-only

Liste les réunions de l'utilisateur. Pagination et filtres par statut et date. Utile pour répondre à « quelles sont mes réunions récentes ? » ou « liste les réunions du mois dernier ».

ParametersJSON Schema

Name	Required	Description
`status`	No	Filtrer par statut de transcription
`from`	No	Date ISO 8601 (ex: 2026-01-01) — borne inférieure sur created_at
`to`	No	Date ISO 8601 — borne supérieure sur created_at
`page`	No	Numéro de page (défaut 1)
`per_page`	No	Éléments par page (1–100, défaut 25)

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint. Description adds pagination and filtering behavior already in schema. No additional details like ordering or limitations, but no contradiction. Acceptable with annotation coverage.

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?

Two concise sentences front-loading the core action and usage examples, with no wasted words.

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 list tool with 5 parameters and no output schema, the description is complete enough for the main purpose. Could mention return format (e.g., array of meetings) but not essential given typical expectations.

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 covers 100% of parameters with descriptions. Tool description does not add extra meaning beyond what the schema provides, meeting baseline expectation.

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 lists user meetings with pagination and filters by status and date, and gives example queries. It distinguishes from sibling tools like get_meeting (single) and search_meetings.

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?

Provides example use cases for listing recent meetings or last month's meetings, implying context. Does not explicitly state when not to use or mention alternatives, but the context is clear enough.

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

search_meetingsRechercher dans les réunionsA

Read-only

Recherche full-text dans les titres, transcriptions et synthèses de l'utilisateur. Utile pour « trouve-moi la réunion où on a parlé de X ».

ParametersJSON Schema

Name	Required	Description
`q`	Yes	Expression de recherche (mots-clés)
`page`	No	Numéro de page (défaut 1)
`per_page`	No	Éléments par page (1–25, défaut 10)

TDQS

A4/5.0

Behavior3/5

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

Annotations already state readOnlyHint=true, so the description's 'Recherche' confirms read-only behavior. It adds value by specifying the search scope (titles, transcripts, summaries) but does not elaborate on limitations, rate limits, or response format. With annotations present, this is adequate but not exceptional.

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?

Two concise sentences, front-loaded with the core function and followed by a usage example. No unnecessary words.

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 search tool with no output schema, the description covers the key aspects: what is searched and a typical use case. It lacks mention of the return format but remains sufficient for most use cases.

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%, so each parameter already has a description. The tool description does not add any additional meaning beyond what the schema provides. Baseline 3 is appropriate given high coverage.

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 performs full-text search across titles, transcripts, and summaries, and gives an example query. The name 'search_meetings' aligns well, and it is distinct from sibling tools like 'get_meeting' or 'list_meetings'.

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 use case ('trouve-moi la réunion où on a parlé de X'), implying when to use it for content-based retrieval. While it doesn't explicitly exclude alternatives, the sibling tools context provides differentiation.

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.

5 tool updatesv1.1.0Jun 23, 2026
- First observedget_meeting
- First observedget_summary
- First observedget_transcript
- First observedlist_meetings
- First observedsearch_meetings

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a distinct and well-defined purpose: get_meeting returns full details, get_summary returns the summary, get_transcript returns the transcript, list_meetings lists meetings, and search_meetings performs full-text search. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (get_*, list_*, search_*). This predictability helps the agent understand the action and resource for each tool.

Tool Count5/5

With exactly 5 tools, the set is well-scoped for a meeting retrieval service. Each tool covers a core operation without being too many or too few.

Completeness3/5

The tool set is complete for reading and searching meetings, but lacks any write operations (create, update, delete). This is a notable gap for a meeting management server, limiting full lifecycle coverage.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

PithflowOAuth
com.pithflow
Read-only access to your own Pithflow meeting notes, transcripts, dictionary and usage.
Note Taking Knowledge & Memory
1
RecordXOAuth
io.recordx
Read-only access to your RecordX meetings: search transcripts, summaries, action items.
Project Management Note Taking Search
1
memoket A
ai.memoket
Memoket — access your recording transcripts, summaries, and key takeaways over MCP.
Note Taking Knowledge & Memory
72
note1.ai AOAuth
ai.note1
Search meetings, export summaries and transcripts, and manage recordings from any AI tool.
Search Note Taking Communication
1

Related MCP Servers

Vexaofficial
Communication Search
Vexa-ai
A
license
Not graded
quality
B
maintenance
Open-source meeting bot API with MCP server. Search, retrieve, and analyze meeting transcripts from Google Meet, Zoom, and Microsoft Teams directly from your AI tools.
Updated 9 hours ago (2026-09-05 23:52 UTC)
0
2,751
Apache 2.0
migas-mcp
Search Knowledge & Memory Note Taking
blackpilledsoftware-prog
A
license
A
quality
D
maintenance
Enables AI assistants to query local Migas meeting transcripts, including searching, listing meetings, and retrieving speaker contributions, all read-only.
Updated 5 months ago (2026-03-31 23:37 UTC)
5
15
MIT
LogicNotes MCP Server
Note Taking Search Text Summarization
sharveen22
A
license
Not graded
quality
C
maintenance
Read-only MCP server for searching and retrieving LogicNotes meeting notes, including summaries, transcripts, and action items.
Updated 2 months ago (2026-06-26 06:43 UTC)
MIT
voice-notes-mcp
Knowledge & Memory Note Taking
nikoloside
A
license
Not graded
quality
B
maintenance
Read-only MCP server that exposes locally generated voice notes to any MCP client, allowing listing, searching, and reading transcripts, summaries, and knowledge graphs from voice-notes sessions.
Updated a month ago (2026-08-03 05:34 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/HugoF1234/Gilbert-mcp'

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

gilbert-mcp

Installation rapide

Claude Desktop

Claude Code

Cursor

VS Code

Zed

Docker (alternative)

Obtenir une clé API

Tools exposés

Variables d'environnement

Confidentialité & sécurité

Développement

Licence

Support

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Vexaofficial

Latest Blog Posts

MCP directory API