Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Vibe.co MCP Server list my advertisers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for the Vibe CTV/streaming advertising platform.
This server allows AI assistants (like Claude) to interact with your Vibe advertising data securely via the Vibe Streaming API.
Node.js v22 or higher
A Vibe account with API access
A Vibe API key (see Step 1)
Log in to your Vibe account
Navigate to Developer Tool > API Keys
Create or copy your API key
Choose the setup that matches your MCP client:
Add to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"vibe": {
"command": "npx",
"args": ["-y", "vibeco-mcp"],
"env": {
"VIBE_API_KEY": "your-api-key"
}
}
}
}Add to your Claude Code MCP settings (~/.claude/mcp.json or project-level):
{
"mcpServers": {
"vibe": {
"command": "npx",
"args": ["-y", "vibeco-mcp"],
"env": {
"VIBE_API_KEY": "your-api-key"
}
}
}
}In Cursor settings, add an MCP server:
{
"mcpServers": {
"vibe": {
"command": "npx",
"args": ["-y", "vibeco-mcp"],
"env": {
"VIBE_API_KEY": "your-api-key"
}
}
}
}Related MCP server: Google Ad Manager MCP Server
Variable | Required | Default | Description |
| Yes | - | Vibe API key |
| No |
| API base URL (override for testing) |
| No |
| Transport mode: |
| No |
| Host to bind the HTTP server to |
| No |
| Port for the HTTP server |
The server provides 8 tools for full Vibe API coverage:
Tool | Description |
| Check server status and API key configuration |
Tool | Description |
| List all advertiser IDs |
Tool | Description |
| List app IDs for an advertiser |
Tool | Description |
| List campaign details for an advertiser |
Tool | Description |
| Create an async report (rate limited: 15/hr) |
| Check report status and get download URL |
Tool | Description |
| List purchase IDs for an advertiser |
The server exposes data as MCP resources:
Resource URI | Description |
| List all advertiser IDs |
Resource URI | Description |
| App IDs for a specific advertiser |
| Campaign details for a specific advertiser |
The server provides guided prompts for common workflows:
Prompt | Description |
| Guided workflow for creating a campaign performance report |
| Instructions for configuring the Vibe API key |
# Clone the repo
git clone https://github.com/jacob-hartmann/vibeco-mcp.git
cd vibeco-mcp
# Use the Node.js version from .nvmrc
# (macOS/Linux nvm): nvm install && nvm use
# (Windows nvm-windows): nvm install 22 && nvm use 22
nvm install
nvm use
# Install dependencies
pnpm install
# Copy .env.example and configure
cp .env.example .env
# Edit .env with your API key# Development mode (auto-reload)
pnpm dev
# Production build
pnpm build
# Production run
pnpm startYou can use the MCP Inspector to debug the server:
# Run from source
pnpm inspect
# Run from built output
pnpm inspect:distpnpm inspect loads .env automatically via dotenv (see .env.example).
Contributions are welcome! Please see CONTRIBUTING.md for guidelines on how to contribute to this project.
See SECURITY.md for security policy and reporting vulnerabilities.
This is a community project provided "as is" with no guaranteed support. See SUPPORT.md for details.
MIT © Jacob Hartmann
List all advertiser IDs available to your Vibe API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds the context that the list is scoped to the API key and returns IDs, but does not elaborate on return format, pagination, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loaded with the action and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, an output schema, and comprehensive annotations, the description provides all necessary context. The agent can correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no parameter info, but this is acceptable given zero parameters. Baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'advertiser IDs', and the scope 'available to your Vibe API key'. It distinguishes from sibling tools like vibe.apps.list and vibe.campaigns.list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context is implied by the tool's simplicity and sibling names, but lacks explicit 'when-not-to-use' or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all app IDs for a specific advertiser.
| Name | Required | Description | Default |
|---|---|---|---|
| advertiser_id | Yes | The advertiser ID |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, so the description does not need to re-state safety. The description adds that the tool returns app IDs (not full objects), which is useful but not a major behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence of 8 words with no redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and simple input, the description is adequate for a basic list operation. However, it lacks information about edge cases (e.g., invalid advertiser_id, pagination) that an agent might need for robust usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description ('The advertiser ID'). The tool description echoes the purpose but adds no new meaning beyond the schema's field name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'List', the resource 'all app IDs', and the scope 'for a specific advertiser', making the tool's purpose very clear. It distinguishes from sibling tools (e.g., vibe.advertisers.list) by focusing on apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., vibe.campaigns.list for campaigns). It only states what the tool does, not when it should be chosen over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List campaign details for a specific advertiser.
| Name | Required | Description | Default |
|---|---|---|---|
| advertiser_id | Yes | The advertiser ID |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, which cover safety and behavior. The description adds no further behavioral context beyond stating the action 'list', which is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the essential purpose without any waste. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one required parameter, good annotations, and existing output schema, the description provides enough context for a typical agent. It could mention that campaigns are returned for the given advertiser, but that is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter advertiser_id, with a schema description. The tool description reiterates the need for an advertiser but adds no new semantic information beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists campaign details for a specific advertiser, using a specific verb and resource. It distinguishes from sibling tools like vibe.advertisers.list and vibe.apps.list by specifying the scope (for a specific advertiser) and resource (campaigns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates usage requires an advertiser_id, and by naming sibling list tools, context is provided for when to use this tool. However, it does not explicitly mention when not to use it or provide direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the Vibe MCP server is running and that API credentials are configured. Does not make any API calls to Vibe.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly and idempotent. Description adds that no API calls are made, providing extra behavioral insight 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences conveying full purpose and key behavior. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a health-check tool. Explains what it does and what it doesn't do. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description adds no param info. Baseline 4 is appropriate for 0-param tool with 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool checks server status and credential configuration. Distinct from sibling tools that list or create resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes no API calls are made, implying safe diagnostic use. Lacks explicit when-not or alternative suggestions, but context with siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List purchase IDs for a specific advertiser.
| Name | Required | Description | Default |
|---|---|---|---|
| advertiser_id | Yes | The advertiser ID | |
| start_date | No | Filter start date (YYYY-MM-DD) | |
| end_date | No | Filter end date (YYYY-MM-DD) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint. Description adds 'purchase IDs' return focus but doesn't disclose pagination, ordering, or other behaviors beyond basic read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameters and presence of output schema, description is mostly complete. Could mention date range filtering explicitly, but context signals show 100% schema coverage so deficiency is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for all 3 parameters. Description only reinforces 'for a specific advertiser' which matches the required advertiser_id. No new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List purchase IDs for a specific advertiser' – a specific verb+resource and scope. Distinguishes from sibling tools (e.g., vibe.campaigns.list) by focusing on purchases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., vibe.purchases.list vs other list tools). No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an async report for a Vibe advertiser. Returns a report_id to check status with vibe.reports.status. Rate limited to 15 requests per hour.
| Name | Required | Description | Default |
|---|---|---|---|
| advertiser_id | Yes | The advertiser ID | |
| start_date | Yes | Report start date (YYYY-MM-DD) | |
| end_date | Yes | Report end date (YYYY-MM-DD) | |
| metrics | Yes | Metrics to include in the report | |
| dimensions | No | Dimensions to group by | |
| timezone | No | Timezone for the report | |
| granularity | No | Time granularity | |
| attribution_window | No | Attribution window | |
| event_time_selection | No | Event time selection mode | |
| filters | No | Filters to apply | |
| format | No | Report output format |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds async nature, rate limit, and return of report_id beyond annotations (readOnlyHint false, idempotentHint false). Does not fully detail mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with action and outcome, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers async, rate limit, and report_id; with output schema present, it's sufficient but could elaborate on report content or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions; description adds no extra parameter meaning beyond generic 'for a Vibe advertiser'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Create', resource 'async report for a Vibe advertiser', and distinguishes from sibling 'vibe.reports.status' which checks status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions rate limiting and to use vibe.reports.status for status, but lacks explicit when-to-use vs alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an async report. Returns status and download URL when complete.
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes | The report ID to check |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, openWorldHint) already convey safety and idempotency; description adds that it returns download URL when complete, adding value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one param, output schema present, annotations provided. Description covers purpose and key output, no missing critical info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already describes the parameter as 'The report ID to check'. Description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'check' and resource 'status of an async report', and mentions return of status and download URL. Distinguishes from sibling vibe.reports.create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for checking after creating a report, but no explicit when-to-use, when-not-to-use, or alternative references beyond sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0-rc.2vibe.advertisers.listvibe.apps.listvibe.campaigns.listvibe.pingvibe.purchases.listvibe.reports.createvibe.reports.statusEach tool targets a distinct resource (advertisers, apps, campaigns, etc.) with clear actions, even the two report tools are well-separated by create vs status. No overlap or ambiguity.
All tools follow the same 'vibe.<resource>.<action>' pattern (e.g., vibe.advertisers.list, vibe.reports.create). The only exception is vibe.ping, which is a standalone health check, but it's still consistent in style.
With 7 tools, the set is scoped well for a media platform server covering listing, reporting, and health checks. It is neither too few nor too many, filling a useful niche.
The server covers listing of key resources and async report creation/status, which aligns with its apparent purpose. However, it lacks CRUD for advertisers, campaigns, and purchases, which could be considered minor gaps for a more complete management interface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage your Vidalytics videos and analytics from your AI assistant.
Conversational access to advertising performance data, creative analysis, and campaign insights
Conversational access to advertising performance data, creative analysis, and campaign insights
Build, edit and sync Google, Microsoft, Reddit and Meta ad campaigns from your assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jacob-hartmann/vibeco-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
