Skip to main content
Glama
AlexandreCalvet

Ogury MCP Server

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

  1. 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_here

Local 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 tools
get_campaign_detailsC

Get campaign performance details by campaign ID

ParametersJSON Schema
NameRequiredDescriptionDefault
accountIdNoOptional account ID filter
brandIdNoOptional brand ID filter
campaignIdYesThe campaign ID to retrieve details for
endDateYesEnd date in YYYY-MM-DD format (required)
startDateYesStart date in YYYY-MM-DD format (required)

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
accountIdNoAccount IDs (comma-separated)
brandIdNoBrand ID
campaignIdNoCampaign ID
endDateYesEnd date in YYYY-MM-DD format (required)
identifier1NoExternal identifier 1
identifier2NoExternal identifier 2
identifier3NoExternal identifier 3
startDateYesStart date in YYYY-MM-DD format (required)

TDQS

C2.6/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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

C2.7/5.0
Disambiguation2/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness2/5

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

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that allows accessing and managing ledger files through Claude by providing account listing, balance checking, and transaction register viewing capabilities.
    4
    GPL 3.0
  • A
    license
    A
    quality
    C
    maintenance
    An 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.
    2
    502
    MIT
  • A
    license
    B
    quality
    D
    maintenance
    MCP server that allows Claude AI to interact directly with MySQL databases, enabling query execution and table information retrieval through natural language.
    1
    5
    4
    MIT

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/AlexandreCalvet/ogury-mcp-server-test'

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