Provides tools for Amazon DSP (Delivery Service Partner) operations, including scorecard metrics, DNR investigations, DCR/POD metrics, driver quality, and related operational data.
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., "@CortexDSP MCP show me this week's DNR cases and who delivered each package"
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.
An open-source MCP server for Amazon DSP (Delivery Service Partner) operations. Ask Claude about your scorecard, DNR investigations, DCR/POD metrics and more — right from Claude Desktop or claude.ai.
The demo tools work offline with zero setup. Plug in a CortexDSP API key and the server also exposes your real operation's data (DNR cases, who-delivered, scorecard comparisons, driver quality…) — securely proxied from the hosted API.
Built for AMZL DSPs who are tired of Amazon's slow, fragmented dashboards.
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"cortexdsp": {
"command": "npx",
"args": ["-y", "cortexdsp-mcp"]
}
}
}Restart Claude Desktop. You now have the free demo tools. To unlock your own data, add your key:
{
"mcpServers": {
"cortexdsp": {
"command": "npx",
"args": ["-y", "cortexdsp-mcp"],
"env": { "CORTEXDSP_API_KEY": "your-key-here" }
}
}
}Get a key at cortexdsp.com.
Related MCP server: RBPaaS MCP Server
Tool | What it does |
| Scorecard metrics and their Fantastic targets (DCR, POD, DSC, DNR, LoR…). |
| What a metric means and how it's computed ( |
| How a DNR (Did Not Receive) investigation is answered — the completion→location→detail cascade. Educational; sends nothing. |
| Typical weekly ranges for lost / potential-not-on-van packages. |
| How many returns you can have and still hit a target DCR. |
dnr_list, missing_pnov, who_delivered, scorecard_compare, driver_quality, mentor_status, mail_list, and more — scoped to your tenant. These are proxied from api.cortexdsp.com; this repo contains no business logic or credentials.
Claude ──stdio──> cortexdsp-mcp (this repo)
├─ demo tools → answered locally, no data
└─ your-data tools → proxied to api.cortexdsp.com with your keyThe same package serves everyone: without a key you get the demo tools; with a valid key + active subscription, your real tools are registered by proxy. If a key is missing or invalid, you simply fall back to the demo tools.
This repo never contains API tokens, credentials, or internal endpoints.
Your key lives only in your local MCP config and is sent to api.cortexdsp.com over HTTPS.
Demo tools are fully self-contained and cannot read any customer data.
npm install
npm test # unit tests (node:test)
npm start # run the server over stdioMIT © CortexDSP
Educational: how a DNR (Did Not Receive) investigation is answered — the completion→location→detail cascade. Sends nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral trait 'Sends nothing' (no side effects), which is valuable, but it does not describe the return format or whether the explanation is fixed or generated.
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 short clauses, front-loaded with the educational framing and the cascade model, followed by the no-side-effects note. No wasted language.
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 zero-parameter educational tool with no output schema, the description conveys purpose and the no-op behavior. It could say more about what the response looks like, but the essential call context is present.
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 zero parameters, so there is no parameter semantics to document. Baseline 4 applies; no schema details are missing.
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 a specific educational purpose: explaining how a DNR investigation is answered via the completion→location→detail cascade. The verb 'Educational' plus the named process is clear, though sibling differentiation is only implicit via 'Sends nothing'.
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?
It does not say when to use this tool versus the sibling educational/analytical tools (dsp_thresholds, explain_metric, etc.). The only usage-adjacent cue is 'Sends nothing,' which implies safety but not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Indicative Amazon DSP scorecard metrics and their Fantastic targets (DCR, POD, DSC, DNR, LoR…).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. The zero-parameter shape makes mutation risk effectively nil, so the practical gap is small, but the description never confirms this is a static reference lookup with no side effects, nor whether the target values are current or illustrative ('Indicative' suggests the latter but is ambiguous).
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?
A single efficient sentence with the resource and its payload front-loaded. The trailing ellipsis and unexplained 'Fantastic' label slightly weaken precision, but there is no padding.
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 zero-param reference tool with no output schema, the description should convey the shape of the return (a metric-to-target mapping, presumably) and what the acronyms stand for. It gestures at this but leaves the return structure and the tier concept ('Fantastic') unexplained.
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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The listed acronyms add framing but no parameter-level meaning is needed or missing.
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?
It says the tool surfaces Amazon DSP scorecard metrics and their target values, and lists representative acronyms (DCR, POD, DSC, DNR, LoR). But the verb is implicit and the qualifier 'Fantastic targets' is undefined jargon that an agent can't interpret without prior context. Nothing distinguishes it from siblings like explain_metric or pnov_benchmark.
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 statement of when to call this versus explain_metric (definitions) or pnov_benchmark (benchmarks), even though those siblings overlap conceptually with 'metrics and targets'. There are no exclusions or preconditions at all; usage must be inferred from the one-line purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain what a DSP scorecard metric means and how it is computed (dcr, dsc, dnr, pod, lor, ementor).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
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 explains meaning and computation (i.e., returns descriptive information rather than computing live values), which is a useful behavioral clue, but it omits details like output format, whether it's static documentation, and any permissions or side effects.
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?
A single, front-loaded sentence that states the action, resource, and scope with zero wasted words. It is appropriately sized for a simple lookup tool.
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 one-parameter informational tool with no annotations or output schema, the description covers the basic purpose but leaves key gaps: it does not explain the metric codes, clarify return format, or distinguish this tool from similarly named siblings. It is adequate but incomplete.
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 0%, so the description should compensate. It lists the enum values (dcr, dsc, dnr, pod, lor, ementor) but does not explain what any of these acronyms mean or how to choose between them, so it adds little semantic value beyond the schema's enum.
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 a specific verb (Explain) and resource (DSP scorecard metric meaning and computation), making the tool's purpose immediately clear. It does not differentiate from siblings like dsp_thresholds or dnr_response_format, but the core action is unambiguous.
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?
Usage is implied: call this when you need to understand a metric's definition or calculation. However, there is no explicit guidance on when to use this versus sibling tools such as dsp_thresholds or pnov_benchmark, nor any stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Typical weekly ranges for lost / potential-not-on-van packages (aggregated, anonymous).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden; it does disclose that data is 'aggregated, anonymous' (useful privacy/provenance context) and weekly in granularity. It says nothing about return shape, whether ranges are per-carrier/per-week, or how the benchmark is computed.
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?
A single sentence with no waste, and the 'typical weekly ranges' scope is front-loaded. It loses a point only because the undefined acronym makes the lead harder to parse than it should be.
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 no output schema, the description is the only source of return information; 'typical weekly ranges' hints at the payload but doesn't specify units, percentile bounds, or time basis. For a simple no-arg lookup that may be enough, but it's thin.
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 takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description doesn't misleadingly imply any inputs.
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?
States the resource (typical weekly ranges for lost / potential-not-on-van packages) but never uses a verb and never expands the 'pnov' acronym, so the agent must infer both the action and the domain. The subject matter is distinct from siblings, but that differentiation is incidental rather than stated.
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?
There is no indication of when to call this versus dsp_thresholds, return_budget, or explain_metric, and no mention of prerequisites or intended callers. The agent is left to guess the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many returns (RTS) you can have and still hit a target DCR. Pure calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| targetDcr | No | ||
| dispatched | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Pure calculator' is a genuinely useful disclosure that the tool computes rather than queries and presumably has no side effects, but nothing is said about the default for the optional targetDcr, boundary behavior, or what form the answer takes.
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 tight sentences with the core result front-loaded and no filler. Slightly cryptic, but no sentence is wasted.
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 two-parameter pure function with no output schema, the description covers the gist but leaves the required parameter and the DCR definition unaddressed. It is minimally viable rather than complete.
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 0% for two parameters. The description only loosely maps to targetDcr and never mentions 'dispatched' (the sole required parameter) or what its unit is; it also omits what happens if targetDcr is left out, which is the most important semantic gap given it is optional.
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 a specific computational result — how many returns are allowed given a target DCR — which is more than a restatement of the name. However, it leans on unexplained domain jargon (RTS, DCR) and makes no attempt to distinguish itself from siblings like dsp_thresholds or pnov_benchmark, which sound like similar threshold calculators.
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?
There is no statement of when to call this versus dsp_thresholds or explain_metric, and no mention of prerequisites. 'Pure calculator' hints that it is a planning/what-if tool rather than a data lookup, but the agent must infer that rather than being told.
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.
v0.1.0dnr_response_formatdsp_thresholdsexplain_metricpnov_benchmarkreturn_budgetScored across 5 tools
Each tool has a fairly distinct role: thresholds, metric explanation, DNR response guidance, PNOV benchmarks, and a return-budget calculator. The main overlap is that explain_metric includes DNR while dnr_response_format focuses on DNR procedure, and return_budget and dsp_thresholds both involve DCR targets, but descriptions provide enough separation.
Names mix noun phrases (dsp_thresholds, pnov_benchmark, return_budget), a verb phrase (explain_metric), and a longer noun phrase (dnr_response_format). The pattern is readable but not consistent, making it harder to predict tool names.
Five tools is well-scoped for a reference and calculator server focused on DSP scorecard metrics. Each tool appears to earn its place without being thin or excessive.
The surface covers metric targets, explanations, DNR response format, PNOV benchmarks, and a return-budget calculator, which is solid lifecycle coverage for the apparent educational domain. Minor gaps exist, such as no general-purpose calculator for arbitrary metric/target tradeoffs beyond returns, but agents can work around this.
Amazon Seller Central, Ads and Vendor Central in ChatGPT & Claude. 106 tools; writes need approval.
Amazon Seller Central and Ads inside Claude or ChatGPT. Real fees from your own settlements.
Connect Amazon Seller Central to Claude or ChatGPT via MCP. Orders, inventory, pricing, fees, FBA.
GA4, Google Ads and Search Console in Claude. Read-only OAuth, multi-account for agencies.