OMOS-MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP port to listen on (default 8000) | |
| PUBLIC_URL | No | Public URL of the server (for OAuth mode) | |
| OAUTH_ISSUER | No | OAuth issuer (for OAuth mode with Claude.ai / ChatGPT web) | |
| OMOS_DEADLINE | No | Maximum time per tool call in seconds (default 20) | |
| OAUTH_AUDIENCE | No | OAuth audience (for OAuth mode, e.g. https://<app>.onrender.com) | |
| OMOS_INDEX_TTL | No | Cache TTL for project list in seconds (default 300) | |
| OMOS_AUTH_TOKEN | No | Bearer token that HTTP clients must send (for HTTP mode) | |
| OMOS_HTTP_TIMEOUT | No | HTTP timeout per request to Google Drive in seconds (default 20) | |
| OMOS_ROOT_FOLDER_ID | Yes | Folder ID of the root OMOS shared drive (required) | |
| GOOGLE_SERVICE_ACCOUNT_JSON | Yes | Content of the Google service account key JSON, or path to the key file (required) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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). |
| omos_searchA | Full-text search across the OMOS drive. Returns matching files with project path and link; use omos_read on the ids to read content. Args: query: keyword or phrase (searches file content and names) project: optional exact project name from omos_index to narrow the search section: optional section name (e.g. 'BRD', 'Timeline', 'Design', 'DB') to narrow further |
| 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 |
| omos_refreshA | Rebuild the drive index so newly added projects/files show up immediately (the index is otherwise cached for a few minutes). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
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.
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.
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.
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.