Skip to main content
Glama
deenesjakoruzh
Pd011161

OMOS-MCP

by Pd011161
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

OMOS-MCP

MCP server for AI agents (Claude, ChatGPT, Cursor, etc.) to read project documents from OMOS Shared Drive and answer questions — every answer cites the source file with a Google Drive link.

Supported Drive structure:

OMOS/
├── Project A/
│   ├── Project Overview/
│   ├── Timeline/
│   ├── Design/
│   │   ├── System Flow/
│   │   ├── DB/
│   │   └── API/
│   └── BRD/
└── Project B/ ...

Tools

Tool

Description

omos_index

Indexes the entire Drive: all projects + all files with id and link (agent always calls this first)

omos_search

Full-text search across the entire Drive, scoped by project/section

omos_read

Reads a file as text — Google Docs/Sheets/Slides, PDF, .docx, .xlsx, md/text, and images (shows image directly to agent)

omos_refresh

Rebuilds the index immediately (default cache is 5 minutes)

Agent searches in order: filter by Project Name → if not found, check Project Overview then ask user for confirmation → continue asking about Timeline | BRD | Design (System Flow / DB / API) → if the question is too broad, it will ask back to narrow scope (embedded in server instructions).

Related MCP server: brkt-gdrive-mcp

One-Time Setup: Service Account

The server accesses Drive with a service account (no need for everyone to log in):

  1. Go to console.cloud.google.com → create a new project (or use an existing one)

  2. APIs & Services → Library → search for Google Drive API → click Enable

  3. IAM & Admin → Service Accounts → Create Service Account → set a name like omos-mcp → click Create (skip role step, no permissions needed)

  4. Go to the created service account → tab Keys → Add Key → Create new key → JSON → the key file will download

  5. Copy the service account email (looks like omos-mcp@<project>.iam.gserviceaccount.com) and share the Shared Drive / OMOS folder with this email as Viewer

  6. Find the folder id of the root OMOS: open the folder in a browser and look at the URL https://drive.google.com/drive/folders/<this is the id>

Environment Variables

Variable

Description

OMOS_ROOT_FOLDER_ID

Folder id of the root OMOS (from step 6) — required

GOOGLE_SERVICE_ACCOUNT_JSON

The entire JSON key file content or path to the file — required

OMOS_AUTH_TOKEN

(HTTP mode) Bearer token that the client must send

OMOS_INDEX_TTL

Index cache lifetime in seconds (default 300)

OAUTH_ISSUER / OAUTH_AUDIENCE / PUBLIC_URL

(HTTP mode) Enables OAuth mode for Claude.ai / ChatGPT web

PORT

(HTTP mode) Port to listen on (default 8000)

Run Locally

Install uv first (curl -LsSf https://astral.sh/uv/install.sh | sh)

1) Set up .env (server loads it automatically from repo root):

cp .env.example .env

Edit .env to add OMOS_ROOT_FOLDER_ID and the key file path (e.g., place the key file at ./service-account.json — it's already gitignored).

2) Connect with Claude Code (stdio):

claude mcp add omos -- uv run --directory "/path/to/OMOS-MCP" omos-mcp

Claude Desktop / Cursor / Windsurf — add to MCP config:

{
  "mcpServers": {
    "omos": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/OMOS-MCP", "omos-mcp"]
    }
  }
}

3) Test: Ask the agent "What projects are in OMOS?" — you should get a list of projects with links.

(Optional) Run as an HTTP server locally: Enable OMOS_AUTH_TOKEN in .env, then

uv run omos-mcp-http

The endpoint is at http://localhost:8000/mcp; connect with:

claude mcp add --transport http omos http://localhost:8000/mcp -H "Authorization: Bearer <OMOS_AUTH_TOKEN>"

Deploy as an MCP Link (Render)

  1. Push this repo to GitHub (includes Dockerfile + render.yaml)

  2. Render → New → Blueprint → select this repo

  3. Set environment variables in the dashboard:

    • OMOS_ROOT_FOLDER_ID = folder id of the root OMOS

    • GOOGLE_SERVICE_ACCOUNT_JSON = the entire JSON key file content (paste directly)

    • OMOS_AUTH_TOKEN Render generates it automatically → copy and share with the team

  4. Deployment complete → endpoint is https://<app>.onrender.com/mcp

Users connect:

claude mcp add --transport http omos https://<app>.onrender.com/mcp \
  -H "Authorization: Bearer <OMOS_AUTH_TOKEN>"

Cursor / VS Code: Add URL + header Authorization: Bearer <token> in MCP config

Use with Claude.ai / ChatGPT (Web) — OAuth

Web clients cannot pass headers, so OAuth is required through a provider like WorkOS AuthKit (free for up to 1M users):

  1. Sign up at workos.com → enable AuthKit → set login method + restrict to team members only

  2. Dashboard → Connect → Configuration → enable Client ID Metadata Document and Dynamic Client Registration

  3. Add Resource Indicator = https://<app>.onrender.com (without /mcp)

  4. Set 3 additional env variables on Render: OAUTH_ISSUER = AuthKit domain, OAUTH_AUDIENCE = https://<app>.onrender.com, PUBLIC_URL = https://<app>.onrender.com

  5. Users: Claude.ai → Settings → Connectors → Add custom connector → enter https://<app>.onrender.com/mcp → log in via WorkOS

OAuth mode and bearer token can coexist — web uses OAuth, CLI can still use the token

Test Converters

uv run python test_convert.py

Available Tools

4 tools
omos_indexA

Get the full index of the OMOS drive: every project and its files (with file ids and links). Use this whenever the user asks about any internal project, BRD, timeline, design, system flow, DB, API, or เอกสารโปรเจค — ALWAYS call this first, then filter by Project Name before drilling into Timeline / BRD / Design (System Flow, DB, API).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It explicitly states the tool returns the full index of every project with file IDs and links, and implies a read-only operation (no side effects). It does not mention performance, caching, or rate limits, but the zero-parameter nature and output schema presence mitigate the need for deeper behavioral detail. The description adds meaningful context beyond the empty schema and missing 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?

The description is concise at three sentences with no wasted words. The first sentence clearly states the core purpose and what is returned. The second sentence provides specific when-to-use guidance. The third sentence prescribes the correct invocation sequence. Every sentence adds distinct value and the critical usage instructions are 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?

Given the tool has zero parameters and an output schema, the description covers all necessary aspects: what the tool returns (full index of projects and files with IDs and links), when to use it (specific user query scenarios), and how to use it correctly (call first, then filter by project name before drilling into details). The presence of an output schema reduces the need to describe return values, and the description's guidance is fully self-contained.

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 and 100% schema coverage, meaning there is nothing for the description to add about parameters. The description correctly stays silent on parameters (there are none) and instead focuses on what the tool returns and when to use it. A slight deduction because the description could explicitly state 'no arguments required' to confirm no parameters are needed.

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 starts with a clear verb+resource combination: 'Get the full index of the OMOS drive' and immediately specifies the exact content: every project and its files with IDs and links. It thoroughly distinguishes itself from siblings like 'omos_search' by stating it returns the full unfiltered index, while also providing specific use cases where this tool should be used first.

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?

The description gives explicit when-to-use guidance: 'whenever the user asks about any internal project, BRD, timeline, design, system flow, DB, API, or เอกสารโปรเจค.' It also provides a sequence: 'ALWAYS call this first, then filter by Project Name before drilling into Timeline / BRD / Design.' This effectively differentiates from omos_search (which presumably handles the filtering step) and sets clear expectations for invocation order.

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

omos_readA

Read a file from the OMOS drive as text (Google Docs/Sheets/Slides, PDF, docx, xlsx, markdown/text) or as an image (png/jpg). The response starts with a citation block (file name, path, link) — always include that citation in your answer.

Args: file_id: the Drive file id from omos_index or omos_search

ParametersJSON Schema
NameRequiredDescriptionDefault
file_idYes

TDQS

A4.4/5.0
Behavior4/5

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

The description discloses key behaviors: it returns text or image content, starts with a citation block that must be included in answers, and accepts a Drive file ID from omos_index or omos_search. Since no annotations are provided, the description carries the full burden and provides solid behavioral context without contradictions.

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 short and well-structured: a one-sentence overview of what the tool does (including format types), then a specific instruction about the citation block, and finally a clear parameter description. Every sentence adds value, and the most critical information is front-loaded.

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 the tool has only one parameter, limited schema, and no output schema, the description is complete for its simplicity. It explains the input, output format (including citation), and supported file types. A small gap is not explaining how the output type (text vs image) is determined (e.g., by file extension or a parameter).

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 description explains that the file_id parameter should come from omos_index or omos_search, adding meaning beyond the schema's simple type/required. With 0% schema description coverage, the description must compensate, and it does so effectively by specifying the source of valid file IDs.

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 reads a file from the OMOS drive and specifies supported formats (text types and image types). The verb 'read' combined with the resource 'file from OMOS drive' provides a specific, actionable purpose that distinguishes it from sibling tools like omos_index (indexing) and omos_search (searching).

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 gives clear context for when to use this tool (to read a file), and implicitly distinguishes it from omos_index and omos_search which are for listing or searching. However, it does not explicitly state when NOT to use it or mention alternatives for non-file operations.

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

omos_refreshA

Rebuild the drive index so newly added projects/files show up immediately (the index is otherwise cached for a few minutes).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the caching side effect and the rebuild action, but does not mention potential costs (e.g., performance impact), whether it is asynchronous, or any required permissions. The behavior is generally clear but lacks some depth expected for an unannotated tool.

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, well-structured sentence that immediately conveys the action and purpose. No redundant words; every part 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?

For a simple parameterless tool with an output schema, the description covers the core functionality and caching behavior. It could be improved by noting typical usage scenarios (e.g., after uploads) or safe call frequency, but it is largely 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?

There are no parameters; schema description coverage is 100% by default. The description does not need to add parameter details. 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 explicitly states the action ('Rebuild the drive index') and the effect ('so newly added projects/files show up immediately'). It distinguishes itself from sibling tools (index, search, read) by focusing on cache invalidation.

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 on when to use the tool—after adding projects/files to bypass caching. It mentions the default caching behavior ('otherwise cached for a few minutes'), but does not explicitly state when not to use it or list alternative tools for similar purposes.

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. 4 tool updatesv0.1.0
    • First observedomos_index
    • First observedomos_read
    • First observedomos_refresh
    • First observedomos_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: omos_index provides the full index, omos_search performs full-text search with optional filters, omos_refresh rebuilds the index, and omos_read reads file content. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tools follow a consistent 'omos_<verb>' pattern (index, search, refresh, read). The naming is predictable and uniform, making it easy for an agent to understand the action each tool performs.

Tool Count5/5

With 4 tools, the set is well-scoped for a drive retrieval server. Each tool addresses a necessary function (listing, searching, refreshing, reading) without being too few or excessive. The count matches the domain's core operations.

Completeness5/5

The tool surface covers the full read lifecycle for the OMOS drive: obtaining the index, searching, refreshing for updates, and reading file content. No obvious gaps exist for a retrieval-focused server; all necessary operations are present.

Maintenance

ActivityMaintained
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

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/Pd011161/OMOS-MCP'

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