Ogury MCP Server
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., "@Ogury MCP Servershow me campaign 12345 performance from Jan 1 to Jan 31"
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.
Ogury MCP Server An MCP (Model Context Protocol) server that provides Claude with access to Ogury's campaign reporting API.
Features Authentication: Automatic OAuth2 token management with refresh Campaign Details: Get detailed performance metrics for specific campaigns Campaign Reports: Flexible reporting with multiple filter options Error Handling: Comprehensive error handling and logging Tools Available
get_campaign_details Get detailed performance metrics for a specific campaign.
Parameters:
campaignId (required): The campaign ID to retrieve startDate (required): Start date in YYYY-MM-DD format endDate (required): End date in YYYY-MM-DD format accountId (optional): Account ID filter brandId (optional): Brand ID filter Example usage:
"Please provide details about campaign 12345 for the period from 2024-01-01 to 2024-01-31" 2. get_campaigns_report Get campaign performance report with flexible filtering options.
Parameters:
startDate (required): Start date in YYYY-MM-DD format endDate (required): End date in YYYY-MM-DD format accountId (optional): Account IDs (comma-separated) brandId (optional): Brand ID campaignId (optional): Specific campaign ID identifier1/2/3 (optional): External identifiers
Setup
MCP Client Configuration
To use this MCP server with an MCP client (like Claude Desktop), create a configuration file:
mcp-config.json:
{
"mcpServers": {
"ogury": {
"command": "node",
"args": ["dist/index.js"],
"env": {
"OGURY_CLIENT_ID": "your_ogury_client_id_here",
"OGURY_CLIENT_SECRET": "your_ogury_client_secret_here"
}
}
}
}For deployed servers (Railway), use:
{
"mcpServers": {
"ogury": {
"command": "node",
"args": ["dist/index.js"],
"env": {
"OGURY_CLIENT_ID": "your_ogury_client_id_here",
"OGURY_CLIENT_SECRET": "your_ogury_client_secret_here"
}
}
}
}Environment Variables
Create a .env file with your Ogury API credentials:
OGURY_CLIENT_ID=your_client_id_here
OGURY_CLIENT_SECRET=your_client_secret_hereLocal Development Install dependencies: bash npm install Run in development mode: bash npm run dev Build for production: bash npm run build npm start Deployment on Railway Quick Deploy Create Railway Project Go to Railway Create new project from GitHub repo Connect your repository Set Environment Variables In Railway dashboard: OGURY_CLIENT_ID=your_actual_client_id OGURY_CLIENT_SECRET=your_actual_client_secret Deploy Railway will automatically: Install dependencies (npm install) Build the project (npm run build) Start the server (npm start) Railway Configuration Railway will use these commands automatically:
Build Command: npm run build Start Command: npm start Project Structure ogury-mcp-server/ ├── src/ │ └── index.ts # Main MCP server implementation ├── dist/ # Compiled JavaScript (generated) ├── package.json # Node.js dependencies and scripts ├── tsconfig.json # TypeScript configuration └── README.md # This file How It Works Authentication Flow: Server automatically obtains OAuth2 tokens using client credentials Tokens are cached and refreshed automatically (1-hour expiry) Uses HTTP Basic Auth with base64 encoded CLIENT_ID:CLIENT_SECRET API Integration: Wraps Ogury's /v1/reporting/campaigns endpoint Handles authentication headers and error responses Formats data for Claude consumption MCP Protocol: Exposes tools that Claude can invoke Handles tool discovery and execution Returns structured responses to Claude Testing Once deployed on Railway, you can test by asking Claude:
"Please provide details about campaign 12345 from 2024-01-01 to 2024-01-31" Claude will use the MCP server to:
Authenticate with Ogury API Fetch campaign performance data Format and present the results Error Handling The server includes comprehensive error handling for:
Authentication failures API rate limits Network timeouts Invalid parameters Missing environment variables Security Notes Credentials are stored as environment variables Tokens are cached in memory only (not persisted) All API calls use HTTPS No sensitive data is logged Troubleshooting Common Issues Authentication Failed Verify CLIENT_ID and CLIENT_SECRET are correct Check that credentials have proper API access Campaign Not Found Verify campaign ID exists Check date range is valid for the campaign Ensure account/brand filters are correct Railway Deployment Issues Check environment variables are set Verify build logs in Railway dashboard Ensure Node.js version compatibility (18+) Logs Check Railway logs for detailed error information:
Authentication token requests API call responses MCP protocol messages
Available Tools
2 toolsget_campaign_detailsC
Get campaign performance details by campaign ID
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | No | Optional account ID filter | |
| brandId | No | Optional brand ID filter | |
| campaignId | Yes | The campaign ID to retrieve details for | |
| endDate | Yes | End date in YYYY-MM-DD format (required) | |
| startDate | Yes | Start date in YYYY-MM-DD format (required) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's likely non-destructive, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'performance details' entail. This leaves significant gaps for an agent to understand the tool's 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?
The description is a single, direct sentence with no wasted words, clearly front-loading the core action. It is appropriately sized for the tool's complexity, making it efficient and easy to parse.
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 tool has 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return values (e.g., what 'performance details' include), behavioral traits, or usage context, leaving the agent with incomplete information for proper invocation.
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?
The schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no additional parameter semantics beyond implying 'campaignId' is key, so it meets the baseline of 3 without compensating for any gaps.
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 ('Get') and resource ('campaign performance details') with a specific identifier ('by campaign ID'), making the purpose understandable. However, it doesn't explicitly differentiate from the sibling tool 'get_campaigns_report', which might be a broader report vs. specific details, leaving some ambiguity.
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 the sibling 'get_campaigns_report', nor does it mention any prerequisites or alternative contexts. It lacks explicit usage instructions, relying solely on the implied action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_campaigns_reportC
Get campaign performance report with flexible filtering
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | No | Account IDs (comma-separated) | |
| brandId | No | Brand ID | |
| campaignId | No | Campaign ID | |
| endDate | Yes | End date in YYYY-MM-DD format (required) | |
| identifier1 | No | External identifier 1 | |
| identifier2 | No | External identifier 2 | |
| identifier3 | No | External identifier 3 | |
| startDate | Yes | Start date in YYYY-MM-DD format (required) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Get') and mentions 'flexible filtering', but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or what the output format looks like. For a tool with 8 parameters and no annotations, this is insufficient.
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, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for the tool's complexity, though it could be more informative while maintaining brevity.
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 tool's complexity (8 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain what a 'performance report' entails, how filtering works, or what the return values are. For a reporting tool with multiple identifiers and no structured output, more context is needed to guide the agent effectively.
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?
The description adds minimal value beyond the input schema, which has 100% coverage with clear parameter descriptions. The phrase 'flexible filtering' hints at the filtering capability of the parameters but doesn't explain how they interact or provide additional context about the identifiers. With high schema coverage, the baseline score of 3 is appropriate.
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 states the tool 'Get campaign performance report with flexible filtering', which provides a clear verb ('Get') and resource ('campaign performance report'). However, it's somewhat vague about what constitutes 'performance report' and doesn't distinguish it from the sibling tool 'get_campaign_details', leaving ambiguity about their different purposes.
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 mentions 'flexible filtering' but provides no guidance on when to use this tool versus the sibling 'get_campaign_details'. There's no mention of alternatives, prerequisites, or specific contexts where this tool is preferred, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have overlapping purposes, as both retrieve campaign performance data, which could cause confusion for an agent. While 'get_campaign_details' targets a specific campaign by ID and 'get_campaigns_report' offers flexible filtering, the descriptions do not clearly differentiate their use cases, leading to potential misselection.
The tool names follow a consistent verb_noun pattern with 'get_campaign_details' and 'get_campaigns_report', both using snake_case and starting with 'get'. This predictability makes it easy for agents to understand the naming convention.
With only 2 tools, the server feels thin and under-scoped for a campaign management domain, as it lacks essential operations like creating, updating, or deleting campaigns. This limited set may hinder agent workflows and suggests an incomplete implementation.
The tool surface is severely incomplete for campaign management, covering only read operations (details and reports) without any create, update, or delete capabilities. This creates significant gaps that will likely cause agent failures in handling full campaign lifecycles.
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
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Hosted MCP server for Google Ads and LinkedIn Ads analysis.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Marketing intelligence MCP server providing campaign performance data and analytics tools.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAn MCP server that allows accessing and managing ledger files through Claude by providing account listing, balance checking, and transaction register viewing capabilities.4GPL 3.0

Kagi MCP Serverofficial
AlicenseAqualityCmaintenanceAn MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.2502MIT- AlicenseBqualityDmaintenanceMCP server that allows Claude AI to interact directly with MySQL databases, enabling query execution and table information retrieval through natural language.154MIT
- AlicenseDqualityCmaintenanceMCP server that provides Claude AI assistants with the ability to search the web, get news, and perform research using the You.com API.42MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/AlexandreCalvet/ogury-mcp-server-test'
If you have feedback or need assistance with the MCP directory API, please join our Discord server