OSMOS Marketing API MCP Server
# OSMOS Marketing API MCP Server
Model Context Protocol server that exposes the OSMOS Marketing API registry as callable tools, so an AI agent can discover endpoints and make real API calls.
## Structure
```
api_mcp/
├── server.mjs # MCP server (stdio transport)
├── package.json
├── registry/
│ ├── index.json # Root registry (lists services)
│ ├── service/
│ │ └── service.json # Service definition (base URL, auth, hierarchy)
│ └── endpoints/
│ ├── index.json # Endpoint index (15 endpoints)
│ └── *.json # One file per endpoint (OpenAPI-derived)
```
## How it works
1. `server.mjs` loads the registry JSON files at startup.
2. It registers a **tool for every endpoint** in `registry/endpoints/index.json` (named by converting `id` to snake_case, e.g. `create-spa-campaign` → `create_spa_campaign`).
3. Each endpoint tool accepts path params, query params, an optional `body`, plus `x_token` and `x_retailer_id` auth headers.
4. Calling a tool performs the real HTTP request against `https://apiv2.onlinesales.ai/marketing/v1/advertiser` and returns status + parsed response.
### Built-in tools
- `list_endpoints` — list all endpoints (method, path, summary)
- `get_service_details` — service definition (base URL, auth, hierarchy)
- `get_endpoint_definition` — full schema for one endpoint by id
### Resources
- `osmos://service` — service definition
- `osmos://endpoints` — endpoint index
### Prompt
- `campaign-hierarchy` — explains the campaign hierarchy before acting
## Run
```bash
npm install
npm start
```
The server speaks MCP over stdio. Connect it from any MCP client (e.g. Claude Desktop, opencode) using:
```json
{
"mcpServers": {
"osmos-marketing": {
"command": "node",
"args": ["/absolute/path/to/api_mcp/server.mjs"]
}
}
}
```
## Auth
Every API call requires both headers — they are passed as `x_token` and `x_retailer_id` tool arguments:
```
x-token: Authentication token
x-retailer-id: Retailer identifier
```
Without both, the tool returns a clear error explaining they are required.
## Adding a new endpoint
1. Add `registry/endpoints/<endpoint-id>.json` following the existing schema pattern (fields: `endpoint.id`, `method`, `path`, `operationId`, `summary`, `description`, `parameters`, `requestBody`, `responses`, `deprecated`).
2. Add an entry to `registry/endpoints/index.json`.
3. Restart the server — the new endpoint tool is registered automatically.
TDQS
Scored across 18 tools
Each tool targets a distinct resource and action, from API introspection to campaign and sub-resource management. Even the create_update tools are clearly separated by resource type (product set, keywords, category bids).
Most tools follow a consistent verb_noun pattern (create_, list_, get_, update_), but 'save_campaign_network_settings' breaks the pattern by using 'save' instead of 'create_update'. The combined 'create_update' verbs are somewhat unusual but applied consistently.
At 18 tools, the server is within the 16-25 range that feels heavy per calibration. Each tool covers a specific endpoint, but the count is on the higher end for an MCP server.
The tool set covers the campaign lifecycle and all major sub-entities (product sets, keywords, bids, networks, forecast) well. However, there is no delete_campaign tool, which is a notable gap for a CRUD-like surface.