The OpenSincera MCP Server provides access to OpenSincera's publisher data and verification information through its API.
Publisher Lookup: Search for publishers by domain or unique Publisher ID
Metadata Retrieval: Obtain detailed publisher information including verification status, categories, and operational metrics (e.g., ad-to-content ratio, page weight, supply chain complexity, ad refresh rate)
Pagination Support: Retrieve multiple publishers with limit and offset parameters for flexible querying
Health Monitoring: Check the status and connectivity of the OpenSincera API
Error Handling: Comprehensive error handling with detailed error messages
Input Validation: Robust input validation using Zod schemas to ensure correct data submission
Uses Zod schemas for robust input validation of API requests and parameters
Click on "Deploy 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., "@OpenSincera MCP Server get publisher info for cnn.com"
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 that provides access to the OpenSincera API for retrieving publisher metadata, verification information, and advertising quality analytics.
OpenSincera is a platform that provides transparency and verification data for digital advertising publishers. This MCP server allows AI assistants and other tools to access OpenSincera's publisher information, including verification status, metadata, operational metrics, device-level ad quality signals, and competitive benchmarking.
Related MCP server: NewsBreak MCP Server
Publisher Lookup: Search for publishers by domain or Publisher ID
Metadata Retrieval: Get detailed publisher information including verification status, categories, and operational metrics
Device-Level Metrics: Compare mobile vs. desktop A2CR, ads in view, ad refresh rates, and more
Competitive Benchmarking: Compare a publisher against similar publishers side-by-side
Media Evaluation: Score and rank multiple publishers for advertiser media selection
Health Monitoring: Check the status of the OpenSincera API connection
Error Handling: Comprehensive error handling with detailed error messages
Input Validation: Robust input validation using Zod schemas
Install the package globally using npm:
npm install -g opensincera-mcp-serverNode.js 18.0.0 or higher
OpenSincera API key
Clone the repository:
git clone https://github.com/miyaichi/opensincera-mcp-server.git
cd opensincera-mcp-serverInstall dependencies:
npm installBuild the project:
npm run buildSet up environment variables:
export OPENSINCERA_API_KEY="your-api-key-here"
export OPENSINCERA_BASE_URL="https://open.sincera.io/api" # Optional
export OPENSINCERA_TIMEOUT="10000" # Optional (milliseconds)npm startnpm run devAdd the following to your Claude Desktop configuration file, depending on your installation method.
The file is located at:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
If you installed the package globally via npm install -g, the command is directly available in your system's path.
{
"mcpServers": {
"opensincera": {
"command": "opensincera-mcp-server",
"env": {
"OPENSINCERA_API_KEY": "your-api-key-here"
}
}
}
}If you cloned the repository locally, you must provide the full path to the script. Remember to replace /path/to/ with the actual absolute path to the project directory.
{
"mcpServers": {
"opensincera": {
"command": "node",
"args": ["/path/to/opensincera-mcp-server/dist/index.js"],
"env": {
"OPENSINCERA_API_KEY": "your-api-key-here"
}
}
}
}Once configured, you can use these natural language prompts in Claude Desktop:
Check the OpenSincera API connection statusGet publisher information for yahoo.com from OpenSinceraAnalyze the publisher metrics for cnn.com and explain:
- Their verification status
- Ad to content ratio and what it means
- Supply chain complexity
- Overall advertising qualityShow me the mobile vs desktop ad quality metrics for nytimes.comCompare businessinsider.com against its similar publishersEvaluate these publishers for a mobile branding campaign:
- nytimes.com
- washingtonpost.com
- reuters.com
Use device: mobileGet detailed information for OpenSincera Publisher ID 2737I'm considering running ad campaigns on forbes.com.
Can you check their OpenSincera profile and tell me:
- Is this a verified publisher?
- What's their ad refresh rate and is it good or bad?
- How many supply paths do they have?
- Would you recommend this publisher for quality ad placement?These prompts will automatically trigger the appropriate OpenSincera MCP tools and return formatted responses with detailed metric explanations.
Get publisher metadata from OpenSincera API.
Parameters:
publisherId (optional): Publisher ID to search for
publisherDomain (optional): Publisher domain to search for
limit (optional): Maximum number of results (1-100)
offset (optional): Number of results to skip
Note: Either publisherId or publisherDomain must be provided.
Example:
{
"publisherDomain": "example.com"
}Get a single publisher by domain name.
Parameters:
domain (required): Publisher domain to search for
Example:
{
"domain": "example.com"
}Get a single publisher by Publisher ID.
Parameters:
publisherId (required): Publisher ID to search for
Example:
{
"publisherId": "12345"
}Compare a publisher against its similar publishers (competitive benchmark). Retrieves the target publisher and its OpenSincera-curated similar publishers, then generates a side-by-side comparison of key metrics.
Parameters:
domain (required): Publisher domain to benchmark
device (optional): Device type to use for metric comparison — overall (default), mobile, or desktop
Example:
{
"domain": "businessinsider.com",
"device": "mobile"
}Score and rank multiple publisher domains for advertiser media selection. Each publisher receives a score (0–100) based on ad quality metrics, supply chain health, and identity coverage, weighted by campaign goal.
Parameters:
domains (required): List of publisher domains to evaluate
campaignGoal (optional): branding, performance, or balanced (default)
language (optional): Output language — en (default) or ja
device (optional): Device type to use for scoring — overall (default), mobile, or desktop
Example:
{
"domains": ["nytimes.com", "washingtonpost.com", "reuters.com"],
"campaignGoal": "branding",
"device": "desktop"
}Check the health status of the OpenSincera API connection.
Parameters: None
{
"publishers": [
{
"publisherId": "1",
"publisherName": "Business Insider",
"ownerDomain": "insider-inc.com",
"domain": "businessinsider.com",
"status": "active",
"lastUpdated": "2026-04-14T01:00:25.419Z",
"categories": [],
"verificationStatus": "verified",
"parentEntityId": 59072,
"similarPublishers": [41, 67, 405],
"deviceMetrics": {
"mobile": {
"avgAdsToContentRatio": 0.265,
"maxAdsToContentRatio": 1.0,
"minAdsToContentRatio": 0.0,
"avgAdUnitsInView": 1.611,
"maxAdUnitsInView": 4.0,
"averageRefreshRate": 58.441,
"maxRefreshRate": 420.0,
"minRefreshRate": 5.0,
"percentageOfAdSlotsWithRefresh": 98.78
},
"desktop": {
"avgAdsToContentRatio": 0.231,
"maxAdsToContentRatio": 1.0,
"minAdsToContentRatio": 0.0,
"avgAdUnitsInView": 2.577,
"maxAdUnitsInView": 9.0,
"averageRefreshRate": 81.096,
"maxRefreshRate": 590.0,
"minRefreshRate": 5.0,
"percentageOfAdSlotsWithRefresh": 84.99
}
},
"metadata": {
"description": "Business Insider tells the global tech, finance...",
"primarySupplyType": "web",
"avgAdsToContentRatio": 0.249,
"avgAdsInView": 2.088,
"avgAdRefresh": 72.489,
"totalUniqueGpids": 946,
"idAbsorptionRate": 0.5,
"avgPageWeight": 27.843,
"avgCpu": 254.671,
"totalSupplyPaths": 118,
"resellerCount": 69,
"slug": "business-insider"
}
}
],
"totalCount": 1,
"hasMore": false
}{
"healthy": true,
"timestamp": "2026-04-14T10:00:00Z"
}Variable | Description | Default | Required |
| Your OpenSincera API key | - | Yes |
| OpenSincera API base URL |
| No |
| Request timeout in milliseconds |
| No |
The server provides comprehensive error handling for common scenarios:
Authentication errors (401): Invalid or missing API key
Authorization errors (403): Insufficient permissions
Not found errors (404): Publisher not found
Rate limiting (429): API rate limit exceeded
Network errors: Connection issues or timeouts
Validation errors: Invalid input parameters
npm run build - Build the TypeScript project
npm run dev - Run in development mode with hot reload
npm test - Run tests
npm run lint - Run ESLint
npm run format - Format code with Prettier
src/
├── index.ts # Main MCP server entry point and tool definitions
├── opensincera-service.ts # OpenSincera API client and data models
├── metadata-descriptions.ts # Field descriptions and formatted output
└── analysis.ts # Scoring, comparison, and evaluation logicFork the repository
Create a feature branch
Make your changes
Add tests for new functionality
Run the test suite
Submit a pull request
This project is licensed under the MIT License - see the LICENSE file for details.
For issues related to this MCP server, please open an issue on GitHub.
For OpenSincera API issues, please contact OpenSincera support directly.
Added device_level_metrics support: mobile and desktop breakdowns for A2CR, ads in view, ad refresh rate (avg/min/max), and percentage of ad slots with refresh
Added compare_publishers tool: side-by-side competitive benchmark against similar publishers
Added evaluate_media tool: score and rank multiple publishers by campaign goal (branding/performance/balanced)
Added device parameter to compare_publishers and evaluate_media for mobile/desktop-specific analysis
Added analysis.ts module for scoring and reporting logic
Added publisher comparison and rating features
Updated publisher metadata structure with owner_domain, domain, parent_entity_id, and similar_publishers
Version bump and stability improvements
Initial release
Basic publisher lookup functionality
Health check endpoint
Comprehensive error handling
Input validation
Get detailed publisher information by domain name with comprehensive metric descriptions. Returns formatted data including performance metrics, supply chain information, and detailed explanations of each field's meaning and business impact.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Publisher domain to search for |
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 does mention the comprehensive nature of the returned data ('performance metrics, supply chain information, detailed explanations'), which adds useful context about output richness. However, it doesn't address important behavioral aspects like error handling, rate limits, authentication requirements, or whether this is a read-only operation (though 'get' implies it likely is).
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 reasonably concise with two sentences that pack substantial information. The first sentence states the core functionality, while the second elaborates on the return data. There's no obvious fluff or redundancy. However, it could be slightly more front-loaded by mentioning the comprehensive return data earlier.
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 single parameter with full schema coverage and no output schema, the description provides adequate but incomplete context. It helpfully describes the richness of the return data ('comprehensive metric descriptions', 'performance metrics', 'supply chain information'), which compensates for the missing output schema. However, for a tool that returns complex data structures, more detail about the response format would be beneficial.
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 input schema has 100% description coverage, with the single 'domain' parameter clearly documented. The description doesn't add any parameter-specific information beyond what the schema already provides. It mentions 'domain name' but doesn't elaborate on format requirements, validation rules, or examples. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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 tool's purpose: 'Get detailed publisher information by domain name' which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'get_publisher_by_id' by specifying the domain-based lookup approach. However, it doesn't explicitly contrast with 'get_publisher_metadata' which might have overlapping functionality.
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. While it mentions domain-based lookup, it doesn't specify when to choose this over 'get_publisher_by_id' (ID-based lookup) or 'get_publisher_metadata' (which might provide different metadata). There's no mention of prerequisites, error conditions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed publisher information by Publisher ID with comprehensive metric descriptions. Returns formatted data including performance metrics, supply chain information, and detailed explanations of each field's meaning and business impact.
| Name | Required | Description | Default |
|---|---|---|---|
| publisherId | Yes | Publisher ID to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the return content ('formatted data including performance metrics, supply chain information, and detailed explanations') but lacks critical behavioral details such as error handling (e.g., what happens if the ID is invalid), authentication requirements, rate limits, or data freshness. For a read operation with zero annotation coverage, this is a significant gap.
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 appropriately sized and front-loaded, starting with the core purpose. Both sentences earn their place: the first defines the action and scope, and the second elaborates on the return data. There's no unnecessary verbosity, making it efficient for an agent 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's complexity (a single-parameter read operation) and the absence of annotations and output schema, the description is moderately complete. It covers the purpose and return content but misses behavioral aspects like error handling or prerequisites. Without an output schema, it should ideally detail the return structure more explicitly, but it provides enough context for basic use, albeit with gaps.
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 input schema has 100% description coverage, with the single parameter 'publisherId' documented as 'Publisher ID to search for.' The description adds minimal value beyond this, only implying the parameter is used to fetch data. Since the schema already does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't provide additional syntax, format, or usage details for the parameter.
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 tool's purpose: 'Get detailed publisher information by Publisher ID with comprehensive metric descriptions.' It specifies the verb ('Get'), resource ('publisher information'), and key identifier ('Publisher ID'). However, it doesn't explicitly differentiate from sibling tools like get_publisher_by_domain or get_publisher_metadata, which likely retrieve similar data using different identifiers or scopes.
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. It mentions the tool retrieves data by Publisher ID but doesn't compare it to siblings like get_publisher_by_domain (which might use a domain instead) or get_publisher_metadata (which could offer different data types). Without such context, an agent might struggle to choose the correct tool for a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed publisher metadata from OpenSincera API with comprehensive field descriptions. Requires either publisherId or publisherDomain.
Returns publisher information including:
Basic Info: Publisher ID, name, domain, status, verification status, contact info, categories
Performance Metrics: Ads to Content Ratio (A2CR), Ads in View, Ad Refresh Rate, Page Weight, CPU Usage
Supply Chain: Total Supply Paths, Reseller Count, Global Publisher IDs (GPIDs)
Identity: ID Absorption Rate
Each metric includes detailed explanations of what it measures and its business implications.
| Name | Required | Description | Default |
|---|---|---|---|
| publisherId | No | Publisher ID to search for | |
| publisherDomain | No | Publisher domain to search for | |
| limit | No | Maximum number of results to return (1-100) | |
| offset | No | Number of results to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns detailed publisher information with metrics and explanations, which adds behavioral context. However, it lacks details on error handling, rate limits, authentication needs, or response format structure, leaving gaps for a tool with no annotation coverage.
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 appropriately sized and front-loaded, starting with the core purpose and requirements. The bullet-point list efficiently organizes return information, but some sentences could be more concise (e.g., 'Each metric includes detailed explanations...' might be implied). Overall, it earns its place with minimal waste.
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 no annotations and no output schema, the description provides good context on what the tool does and returns, including metric explanations. However, it lacks details on error cases, response format, or pagination behavior (implied by limit/offset but not explained), making it incomplete for full agent understanding without structured data.
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%, so the schema already documents all parameters (publisherId, publisherDomain, limit, offset). The description adds value by specifying that either publisherId or publisherDomain is required, which clarifies semantics beyond the schema's optional parameters. However, it does not provide additional details on parameter interactions or usage examples.
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 tool's purpose with a specific verb ('Get') and resource ('detailed publisher metadata from OpenSincera API'), including comprehensive field descriptions. It distinguishes from sibling tools (get_publisher_by_domain, get_publisher_by_id) by emphasizing comprehensive metadata rather than basic lookup, and explicitly mentions it accepts either publisherId or publisherDomain.
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 clear context for when to use this tool ('Requires either publisherId or publisherDomain') and implies usage for detailed metadata. However, it does not explicitly state when to use this vs. the sibling tools (e.g., get_publisher_by_domain/get_publisher_by_id), which might be for simpler lookups, nor does it mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the health status of the OpenSincera API connection
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe what 'health status' means (e.g., returns success/failure, latency metrics, error details), whether it requires authentication, or what happens on failure. This leaves significant behavioral gaps for a monitoring tool.
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, focused sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential information without unnecessary elaboration.
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 health check tool with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes 'health status' or what the return values might be (e.g., boolean status, detailed diagnostics, error messages). Given the lack of structured fields, the description should provide more operational context.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. Baseline for 0 parameters is 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 action ('Check') and target ('health status of the OpenSincera API connection'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools (which are all publisher-related), though this may not be necessary since health_check serves a distinct monitoring purpose.
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 implies usage for verifying API connectivity, but provides no explicit guidance on when to use it versus alternatives or prerequisites. It doesn't mention if this should be used before other operations or as a diagnostic tool, leaving usage context somewhat vague.
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.
v1.0.0get_publisher_by_domain1 field changedInput schema / additionalPropertiesAdded value: +falseget_publisher_by_id1 field changedInput schema / additionalPropertiesAdded value: +falseget_publisher_metadata1 field changedInput schema / additionalPropertiesAdded value: +falsehealth_check1 field changedInput schema / additionalPropertiesAdded value: +falseget_publisher_by_domainget_publisher_by_idget_publisher_metadatahealth_checkScored across 4 tools
The first three tools (get_publisher_by_domain, get_publisher_by_id, get_publisher_metadata) have overlapping purposes, as they all retrieve publisher information with only slight variations in input parameters, which could cause confusion for an agent. However, the health_check tool is clearly distinct, providing a separate API connection check function.
The tool names follow a consistent verb_noun pattern (e.g., get_publisher_by_domain, health_check), with all using snake_case. The only minor deviation is that health_check uses a compound noun without a preceding verb like 'get', but it still fits the general naming convention.
With only 4 tools, the server feels thin for its apparent domain of publisher analytics, as it lacks operations for updating, creating, or deleting data, which limits functionality. However, the count is reasonable for a basic read-only interface.
The tool set is severely incomplete for a publisher analytics domain, as it only provides read operations (get and health check) without any create, update, or delete capabilities. This creates significant gaps that could lead to agent failures when full lifecycle management is needed.
Domain/IP intelligence, web page capture and search APIs
One API for public web data across social, directories and real estate, as clean JSON.
Enrich and search people and companies, resolve identities, and enrich IP addresses.
OFAC, FDA, federal award and Federal Register lookups with signed machine evidence.
