# io.github.CloudCorpRecords/supprecord (oci · ghcr.io/cloudcorprecords/supprecord)

Dated formula history, confirmed changes, and evidence for U.S. pre-workout supplements.

- Trust score: 38/100 (low)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- npm · `@reneturcios/supprecord`: 67/100, [markdown](https://verifymcp.io/servers/cloudcorprecords-supprecord/reneturcios-supprecord.md), [page](https://verifymcp.io/servers/cloudcorprecords-supprecord/reneturcios-supprecord)
- oci · `ghcr.io/cloudcorprecords/supprecord`: 38/100 (this document), [markdown](https://verifymcp.io/servers/cloudcorprecords-supprecord/ghcr-io-cloudcorprecords-supprecord.md), [page](https://verifymcp.io/servers/cloudcorprecords-supprecord/ghcr-io-cloudcorprecords-supprecord)

## Channel facts

- Registry: `oci`
- Package: `ghcr.io/cloudcorprecords/supprecord`
- Version: `0.1.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 0/100
  - No malware scan is available for this kind of package: the supply-chain vendors we use do not cover it. This is a permanent gap in our coverage, not a finding about the package.
  - Known CVEs could not be checked: this artifact ships no SBOM or dependency manifest, so there is no dependency list to read.
  - Install-script risk not yet assessed.
  - Dependency health could not be checked: this artifact ships no SBOM or dependency manifest, so there is no dependency list to read.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 0 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 65/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 6720 tokens (~373/item across 18 items; 18 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 3/100
  - Stability observed for 1 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "watchlist.remove" implies "remove" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 18 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the io.github.CloudCorpRecords/supprecord MCP server?

io.github.CloudCorpRecords/supprecord runs locally as a container image, launched with docker run --rm -i ghcr.io/cloudcorprecords/supprecord:0.1.0 mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 3 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add cloudcorprecords-supprecord -- docker run --rm -i ghcr.io/cloudcorprecords/supprecord:0.1.0 mcp
```

### Cursor

```json
{
  "mcpServers": {
    "cloudcorprecords-supprecord": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/cloudcorprecords/supprecord:0.1.0",
        "mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "cloudcorprecords-supprecord": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/cloudcorprecords/supprecord:0.1.0",
        "mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add cloudcorprecords-supprecord -- docker run --rm -i ghcr.io/cloudcorprecords/supprecord:0.1.0 mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "cloudcorprecords-supprecord": {
      "type": "local",
      "command": [
        "docker",
        "run",
        "--rm",
        "-i",
        "ghcr.io/cloudcorprecords/supprecord:0.1.0",
        "mcp"
      ],
      "enabled": true
    }
  }
}
```

### Hermes

```yaml
mcp_servers:
  cloudcorprecords-supprecord:
    command: "docker"
    args: ["run", "--rm", "-i", "ghcr.io/cloudcorprecords/supprecord:0.1.0", "mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "cloudcorprecords-supprecord": {
      "Transport": "stdio",
      "Command": "docker",
      "Arguments": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/cloudcorprecords/supprecord:0.1.0",
        "mcp"
      ]
    }
  }
}
```

### Other

```json
{
  "mcpServers": {
    "cloudcorprecords-supprecord": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/cloudcorprecords/supprecord:0.1.0",
        "mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 38, +1)

No change was recorded against any check on this day. Stability & Change Management went from 0 to 3. That category is still filling its 30-day observation window: 0 days of observed history at the previous scan, 1 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-04 (score 37)

First indexed and scored.

## MCP tools (18)

### `record.search` (~379 tokens)

Search record

Answer one specific, bounded question from FormulaSignal's covered pre-workout Record.

When to use: Use for a single natural-language question about a covered product: what it declares now, whether it changed, what it costs per serving, or which covered products meet one stated numeric condition.

What it cannot provide: It cannot list the database, export products, answer medical or suitability questions, or answer about a product FormulaSignal does not cover.

Limits: One question, at most 300 characters. Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `query` (string, required): One plain-language question about covered pre-workout products, for example "How much caffeine is in C4 Original?". Ask once; rewording the same question returns the same answer and costs quota.

### `products.resolve` (~337 tokens)

Resolve product

Resolve a brand, product name, or alias to one canonical covered product.

When to use: Call this first whenever you hold a user-supplied product name and need the canonical product_id every other capability takes.

What it cannot provide: It never guesses. An ambiguous or generic name returns the candidate list and no match, and an uncovered product returns no match at all.

Limits: Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `identifier` (string, required): A brand, product name or alias as the user wrote it, for example "C4 Original".

### `products.get` (~345 tokens)

Get product record

Return the controlled current Record for one covered product: identity, serving configuration, declared ingredients, captured price context, and freshness.

When to use: Use when you need what a product declares right now, with the dates and limitations attached.

What it cannot provide: It returns no preserved source bytes, no internal capture identifiers, no review notes, and no verdict about whether the product is good or suitable.

Limits: Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `product_id` (string, required): A canonical FormulaSignal product id, such as the product_id returned by products.resolve. Not a display name.

### `products.history` (~349 tokens)

Get formula history

Return the controlled historical timeline for one covered product, with each state classified by what it can actually support.

When to use: Use to find out whether a product has changed, how deep the recoverable history is, and which states are comparable to each other.

What it cannot provide: It never presents an observation window as an exact reformulation date, and it never reports an unreviewed candidate as a confirmed change.

Limits: Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `product_id` (string, required): A canonical FormulaSignal product id, such as the product_id returned by products.resolve. Not a display name.

### `signals.explain` (~352 tokens)

Explain signal

Explain one approved FormulaSignal Signal: a confirmed, reviewed change between two comparable product states.

When to use: Use when a product record or history response named a signal_id and you need the before state, the after state, the observation window, and the evidence.

What it cannot provide: It has no access to unreviewed candidates, review deliberation, or the internal review queue. A signal_id that is not approved returns not found.

Limits: Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `signal_id` (string, required): A Signal id, as named by a product record, a formula history, or signals.list.

### `signals.list` (~570 tokens)

List signal changes

Return approved FormulaSignal Signals in release order, newest first, for incremental polling.

When to use: Use to keep a system in step with the Record. Pass `since` with the release date you last saw, or follow `next_cursor`, and filter by product, brand, dimension or category.

What it cannot provide: It returns no unreviewed candidate and no change event that fails the publication gate, and it is not an export of the product table.

Limits: At most 25 Signals per page, newest release first. Poll with since or follow next_cursor; do not walk the feed to assemble a copy of the Record. Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `brand` (string): Only Signals for this brand, matched on the full brand name, case-insensitive.
- `category` (string): Only Signals whose change category matches this value, case-insensitive, as shown in a Signal's change.category field.
- `cursor` (string): The next_cursor value from the previous page. Omit it for the first page.
- `dimension` (string): Only Signals of this kind of change: FORMULA, FORMULA_DOSE, SERVING, PRICE, CLAIMS, CERTIFICATION, LIFECYCLE or OTHER.
- `limit` (integer): Signals per page, 1 to 25. Defaults to the plan's page size.
- `product_id` (string): Only Signals for this canonical product id.
- `since` (string): Only Signals released on or after this date, YYYY-MM-DD. Pass the newest release date you have already seen to poll for what is new.
- `until` (string): Only Signals released on or before this date, YYYY-MM-DD.

### `products.compare` (~360 tokens)

Compare products

Compare two or three covered products on consistent FormulaSignal criteria.

When to use: Use when a user asks how covered products differ on formula, serving economics, stimulant load, or record depth.

What it cannot provide: It returns no overall winner and no suitability judgement. A product whose depth is REGISTERED is refused rather than compared, because a guessed label beside a measured one implies a precision the Record does not have.

Limits: At most 3 products per call, and every product must be at NORMALIZED depth. Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `product_ids` (array, required): Two or three canonical product ids to compare. Resolve names with products.resolve first.

### `products.serving_economics` (~347 tokens)

Get serving economics

Return the captured commercial facts and the deterministic price arithmetic for one covered product.

When to use: Use for package price, price basis, serving count, price per serving, and the date each was observed.

What it cannot provide: It never calls an observed price a list price unless the Record recorded it as one, and it never reports a promotional-versus-list difference as a price change.

Limits: Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `product_id` (string, required): A canonical FormulaSignal product id, such as the product_id returned by products.resolve. Not a display name.

### `ingredients.research` (~388 tokens)

Get research context

Return the dose range used in the selected evidence set for named ingredients, with the citation and its limitations.

When to use: Use to place a declared amount against published work. Pass ingredient ids, or a product_id to read the ingredients that product declares.

What it cannot provide: A dose comparison is not evidence of effectiveness, safety, or suitability for any person, and the response says so on every record.

Limits: Pass ingredient_ids (at most 5) or one product_id, not both. Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `ingredient_ids` (array): Up to five canonical ingredient ids. Pass these or product_id, not both.
- `product_id` (string): A canonical product id, to read the ingredients that product declares. Pass this or ingredient_ids, not both.

### `ingredients.regulatory` (~388 tokens)

Get regulatory context

Return regulatory records and documented cautions for named ingredients, each carrying the class of record it actually is.

When to use: Use when you need to know what filings, advisories, label warnings, interactions, or enforcement actions FormulaSignal holds for an ingredient.

What it cannot provide: A regulatory filing is never returned as an approval, a warning, or a finding of harm. Nothing here is medical clearance.

Limits: Pass ingredient_ids (at most 5) or one product_id, not both. Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `ingredient_ids` (array): Up to five canonical ingredient ids. Pass these or product_id, not both.
- `product_id` (string): A canonical product id, to read the ingredients that product declares. Pass this or ingredient_ids, not both.

### `signals.snapshot` (~438 tokens)

Get category snapshot

Return a bounded summary of approved Signals and coverage state across the covered pre-workout set for a date window.

When to use: Use for 'what changed in the category recently'. Pass from and to dates; the window is capped and the page size is capped.

What it cannot provide: It is not an export. It returns approved Signals inside one bounded window, never the product table and never the underlying Record.

Limits: Bounded window of at most 400 days and at most 25 items per page. Follow next_cursor for more. Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `cursor` (string): The next_cursor value from the previous page. Omit it for the first page.
- `from` (string): Start of the window, YYYY-MM-DD. Defaults to the widest window the plan allows before `to`.
- `limit` (integer): Signals per page, 1 to 25. Defaults to the plan's page size.
- `to` (string): End of the window, YYYY-MM-DD. Defaults to today (UTC).

### `ledger.list` (~346 tokens)

List ledger editions

List the published Category Ledger editions: period, status, data-as-of date and the count released in each.

When to use: Call this first to find which edition covers a period, then fetch that edition by id.

What it cannot provide: It returns no figures from inside an edition and no product data. A closed edition's identity never changes, so this list is safe to cache.

Limits: Identities only. A frozen edition never changes, so its listing and its content are both safe to cache; an in-progress one moves until its period closes. Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

### `ledger.get` (~424 tokens)

Get ledger edition

Return one Category Ledger edition: the executive summary, confirmed changes released in the period, category benchmarks with their cohorts, serving economics, the product comparison, and the limitations.

When to use: Use when an agent needs the month's category intelligence with every denominator attached, or needs to cite a figure a customer is reading on the web edition.

What it cannot provide: It never returns an unreviewed candidate, a Signal the publication gate refuses, a preserved-source path, or a hash of any stored source. The edition_hash it does return is a hash of the published document itself, so a machine citation and the page a person was sent can be checked against each other.

Limits: One edition per call. Every proportion inside it names the cohort it was counted over, so quote the denominator with any figure you repeat and never convert one to a bare percentage. Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `edition_id` (string, required): A Category Ledger edition id, as returned by ledger.list.

### `watchlist.list` (~344 tokens)

List watched products

Return the watchlist of the one Founding Pro account this key is bound to, with each product's monitoring state.

When to use: Use to answer what a person is watching, when each product was last read, when the next check is due, and whether anything is currently unreadable.

What it cannot provide: It reaches exactly one account, the one bound to this key, and no other. It returns no candidate detail, no source URL and no internal identifier, and it is not a way to read the covered set.

Limits: Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

### `watchlist.add` (~368 tokens)

Watch product

Add one covered product to the bound account's watchlist.

When to use: Use when a person asks to start watching a product. Resolve the product first if you were given a name rather than an id.

What it cannot provide: It cannot add a product outside the covered set, exceed the account's watch limit, or act on an account this key is not bound to. It refuses a covered product FormulaSignal cannot monitor yet and says why in the refusal. It does not start a subscription and refuses when the account is not entitled.

Limits: Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `product_id` (string, required): The canonical product id to start watching. Resolve a name with products.resolve first.

### `watchlist.remove` (~316 tokens)

Unwatch product

Remove one product from the bound account's watchlist.

When to use: Use when a person asks to stop watching a product. Future alerts stop; everything already delivered stays.

What it cannot provide: It cannot delete an account, cancel a subscription, or remove history. Removing a watch never removes what was already sent.

Limits: Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `product_id` (string, required): The canonical product id to stop watching.

### `watchlist.receipt` (~364 tokens)

Get watch receipt

Return the monitoring receipt for one period: valid checks, attempts that returned nothing, recoveries, and confirmed Signals.

When to use: Use to answer whether anything a person watches changed in a period, and what monitoring did in the period whether or not anything did.

What it cannot provide: A count of valid checks is not a claim that a product held still. It reports no candidate, no source URL and no internal identifier, and a period the monitoring ledger does not reach is reported as partly covered rather than as zero.

Limits: Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

Input parameters:

- `period` (string): A calendar month, YYYY-MM. Defaults to the current month (UTC).

### `record.version` (~305 tokens)

Get record version

Return the public Record version, the methodology version, the supported category, coverage counts, and source freshness.

When to use: Call this to state which version of FormulaSignal intelligence an answer came from, or to detect that coverage has moved.

What it cannot provide: It exposes no implementation detail, no internal scoring, and no proprietary methodology text.

Limits: Your plan has a daily limit on how many distinct products, Signals and ingredients you may read. Repeating a question about the same product costs nothing extra; reading many different products costs one each. Do not iterate through products, aliases, or date windows to assemble a copy of the Record: it is refused, scored, and can suspend the key.

FormulaSignal covers a defined, counted set of U.S. pre-workout products. Coverage is not the whole category, and a product being absent from coverage says nothing about that product. Every response carries a status. `supported` means the Record answered. `partial`, `stale`, `under_review`, `ambiguous` and `unsupported` are all real answers about the Record and none of them is a fact about the product: report them as what FormulaSignal holds, never as what is true of the product. Read `limitations` and repeat what applies. An observation date is when a source was read, not when a change was made, and an observation window is not an exact reformulation date. Nothing here is medical advice or a suitability judgement for any person.

## Diagnostics

Captured diagnostic sections: Provenance. The full working is on the page: https://verifymcp.io/servers/cloudcorprecords-supprecord/ghcr-io-cloudcorprecords-supprecord#diagnostics

## Score history

- 2026-11-05: 38
- 2026-11-04: 37

## Common questions

### What is the io.github.CloudCorpRecords/supprecord MCP server?

io.github.CloudCorpRecords/supprecord is an MCP server listed in the public MCP registry as io.github.CloudCorpRecords/supprecord. Dated formula history, confirmed changes, and evidence for U.S. pre-workout supplements. This page covers its container image (ghcr.io/cloudcorprecords/supprecord).

### Is the io.github.CloudCorpRecords/supprecord MCP server safe to use?

io.github.CloudCorpRecords/supprecord scores 38 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the io.github.CloudCorpRecords/supprecord MCP server expose?

io.github.CloudCorpRecords/supprecord exposes 18 tools: record.search, products.resolve, products.get, products.history, signals.explain, and 13 more. Their descriptions and schemas cost roughly 6,720 tokens of context every time the server is loaded.

### Is the io.github.CloudCorpRecords/supprecord MCP server still maintained?

io.github.CloudCorpRecords/supprecord is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the io.github.CloudCorpRecords/supprecord MCP server under?

io.github.CloudCorpRecords/supprecord declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

### What did VerifyMCP test on the io.github.CloudCorpRecords/supprecord MCP server?

VerifyMCP ran 12 checks on io.github.CloudCorpRecords/supprecord, covering Source repository, Provenance, License, Maintenance and 8 more. 4 items could not be completed, a gap on our side rather than a finding about io.github.CloudCorpRecords/supprecord: Malware scan, Known CVEs, Install scripts and Dependency health. One category scores 0 for that reason, because we only credit what we can confirm. Endpoint Security and Transport & Reachability do not apply to a container image, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.

## Links

- GitHub Container Registry: https://ghcr.io/cloudcorprecords/supprecord
- Repository: https://github.com/CloudCorpRecords/supprecord
- Changelog RSS feed: https://verifymcp.io/servers/cloudcorprecords-supprecord/ghcr-io-cloudcorprecords-supprecord.xml
- Changelog JSON feed: https://verifymcp.io/servers/cloudcorprecords-supprecord/ghcr-io-cloudcorprecords-supprecord/changelog.json
- Trust report (JSON): https://verifymcp.io/servers/cloudcorprecords-supprecord/ghcr-io-cloudcorprecords-supprecord.json
- HTML version of this page: https://verifymcp.io/servers/cloudcorprecords-supprecord/ghcr-io-cloudcorprecords-supprecord