Skip to main content
  • Create servers per job-to-be-done: Split configurations by user task, not by app. Examples: “Find/answer with company knowledge” (search, chat, read_document), “Engineering context” (code_search), “People and org lookup” (employee_search).
  • Keep tool sets focused: Aim for 3–6 tools per server. Prefer a small, high-signal set over exhaustive coverage. If you need many tools, create multiple servers (e.g., General vs. Engineering).
  • Name servers and tools purpose-first: Use action- and audience-forward names. Examples: server Glean – Engineering, tool search (enterprise search), code_search (repositories), employee_search (people).
  • Prefer native host transports when available: Use direct HTTP where hosts support it (e.g., Cursor, VS Code). For stdio-only hosts, route via mcp-remote bridge. Note: our MCP Host Configurator will generate the correct host configuration for you.
  • Match host constraints: Some hosts expose fewer actions (e.g., ChatGPT supports search/fetch only). Configure a smaller tool surface for those hosts and point users to the MCP Configurator for exact steps.
  • Use OAuth when possible: Default to Glean OAuth for user-scoped permissions. Use tokens only for hosts that cannot perform OAuth or for unattended flows.
  • Prefer linkable, permission-aware results: Include read_document alongside search so hosts can fetch content by ID/URL with permission checks.
  • Segment by data sensitivity when needed: If certain sources (e.g., HR) require tighter control, publish a dedicated server with only the necessary tools and clear labeling.
  • Document per-host endpoints: Use fixed endpoints for managed installs that require them (e.g., similar to how we provide the ChatGPT server at https://[instance-name]-be.glean.com/mcp/chatgpt).
See also:
⌘I