# FormulaSignal (remote · formulasignal.com)

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

- Trust score: 74/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-26

## Components

- remote · `formulasignal.com`: 74/100 (this document), [markdown](https://verifymcp.io/servers/com-formulasignal-record/formulasignal.md), [page](https://verifymcp.io/servers/com-formulasignal-record/formulasignal)

## Channel facts

- Endpoint: `https://formulasignal.com/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, 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-09-26.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 18 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 61/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 6621 tokens (~367/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**: 97/100
  - Stability observed for 29 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 88/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 63% 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; "formulasignal_unwatch_product" implies "remove" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 19 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 60/100
  - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28.

## Install

### How do I install the FormulaSignal MCP server?

FormulaSignal is a hosted endpoint at https://formulasignal.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http com-formulasignal-record 'https://formulasignal.com/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "com-formulasignal-record": {
      "url": "https://formulasignal.com/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-formulasignal-record": {
      "type": "http",
      "url": "https://formulasignal.com/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.com-formulasignal-record]
url = "https://formulasignal.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-formulasignal-record": {
      "type": "remote",
      "url": "https://formulasignal.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-formulasignal-record --url 'https://formulasignal.com/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-formulasignal-record:
    url: "https://formulasignal.com/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "com-formulasignal-record": {
      "Transport": "http",
      "Url": "https://formulasignal.com/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-formulasignal-record -t streamable-http -u 'https://formulasignal.com/mcp'
```

### Other

```json
{
  "mcpServers": {
    "com-formulasignal-record": {
      "type": "http",
      "url": "https://formulasignal.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## 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-09-26 (score 74, +1)

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

### 2026-09-25 (score 73, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-09-24 (score 73, +1)

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

### 2026-09-22 (score 72, +1)

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

### 2026-09-20 (score 71, +1)

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

### 2026-09-17 (score 70, +1)

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

### 2026-09-15 (score 69, +1)

- [security] Tool “formulasignal_watch_product” rewrote its description, which is the text the model reads

### 2026-09-13 (score 68, +1)

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

## MCP tools (18)

### `formulasignal_search_record` (~342 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)

### `formulasignal_resolve_product` (~321 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)

### `formulasignal_get_product_record` (~337 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 id, not a display name.

### `formulasignal_get_formula_history` (~341 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 id, not a display name.

### `formulasignal_explain_signal` (~346 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 canonical FormulaSignal id, not a display name.

### `formulasignal_list_signal_changes` (~446 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)
- `category` (string)
- `cursor` (string)
- `dimension` (string)
- `limit` (integer)
- `product_id` (string): A canonical FormulaSignal id, not a display name.
- `since` (string): A calendar date, YYYY-MM-DD.
- `until` (string): A calendar date, YYYY-MM-DD.

### `formulasignal_compare_products` (~359 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): Canonical FormulaSignal ids. Resolve names with resolve_product first.

### `formulasignal_get_serving_economics` (~338 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 id, not a display name.

### `formulasignal_get_research_context` (~377 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): Canonical FormulaSignal ids. Resolve names with resolve_product first.
- `product_id` (string): A canonical FormulaSignal id, not a display name.

### `formulasignal_get_regulatory_context` (~377 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): Canonical FormulaSignal ids. Resolve names with resolve_product first.
- `product_id` (string): A canonical FormulaSignal id, not a display name.

### `formulasignal_get_category_snapshot` (~388 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)
- `from` (string): A calendar date, YYYY-MM-DD.
- `limit` (integer)
- `to` (string): A calendar date, YYYY-MM-DD.

### `formulasignal_list_ledger_editions` (~351 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.

### `formulasignal_get_ledger_edition` (~428 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 canonical FormulaSignal id, not a display name.

### `formulasignal_list_watched_products` (~347 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.

### `formulasignal_watch_product` (~364 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): A canonical FormulaSignal id, not a display name.

### `formulasignal_unwatch_product` (~321 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): A canonical FormulaSignal id, not a display name.

### `formulasignal_get_watch_receipt` (~352 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)

### `formulasignal_get_record_version` (~308 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: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-formulasignal-record/formulasignal#diagnostics

## Score history

- 2026-09-26: 74
- 2026-09-25: 73
- 2026-09-24: 73
- 2026-09-23: 72
- 2026-09-22: 72
- 2026-09-21: 71
- 2026-09-20: 71
- 2026-09-19: 70
- 2026-09-18: 70
- 2026-09-17: 70
- 2026-09-16: 69
- 2026-09-15: 69
- 2026-09-14: 68
- 2026-09-13: 68
- 2026-09-12: 67
- 2026-09-11: 67
- 2026-09-10: 66
- 2026-09-09: 66
- 2026-09-08: 65
- 2026-09-07: 65
- 2026-09-06: 64
- 2026-09-05: 64
- 2026-09-04: 63
- 2026-09-03: 63
- 2026-09-02: 63
- 2026-09-01: 62
- 2026-08-31: 62
- 2026-08-30: 61
- 2026-08-29: 61
- 2026-08-28: 60

## Common questions

### What is the FormulaSignal MCP server?

FormulaSignal is an MCP server listed in the public MCP registry as com.formulasignal/record. Dated formula history, confirmed changes and evidence for U.S. pre-workout supplements. This page covers its hosted endpoint (https://formulasignal.com/mcp).

### Is the FormulaSignal MCP server safe to use?

FormulaSignal scores 74 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 FormulaSignal MCP server expose?

FormulaSignal exposes 18 tools: formulasignal_search_record, formulasignal_resolve_product, formulasignal_get_product_record, formulasignal_get_formula_history, formulasignal_explain_signal, and 13 more. Their descriptions and schemas cost roughly 6,443 tokens of context every time the server is loaded.

### Does the FormulaSignal MCP server require authentication?

No. We connected to FormulaSignal without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the FormulaSignal MCP server still maintained?

FormulaSignal is still listed as active in the MCP registry. We last reached this channel on 26 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://formulasignal.com/mcp
- Authorisation metadata: https://formulasignal.com/.well-known/oauth-protected-resource/mcp
- Website: https://formulasignal.com/developers
- Changelog RSS feed: https://verifymcp.io/servers/com-formulasignal-record/formulasignal.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-formulasignal-record/formulasignal.json
- HTML version of this page: https://verifymcp.io/servers/com-formulasignal-record/formulasignal