# io.github.farssaadeldin7-ux/diagnose-by-sound (mcpb · diagnose-by-sound.mcpb)

Turn a described vehicle noise into a ranked, testable differential diagnosis with a safety...

- Trust score: 36/100 (low)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-25

## Components

- mcpb · `diagnose-by-sound.mcpb`: 36/100 (this document), [markdown](https://verifymcp.io/servers/farssaadeldin7-ux-diagnose-by-sound/diagnose-by-sound.md), [page](https://verifymcp.io/servers/farssaadeldin7-ux-diagnose-by-sound/diagnose-by-sound)

## Channel facts

- Registry: `mcpb`
- Package: `https://github.com/farssaadeldin7-ux/claude-plugin-suite/releases/download/mcpb-v0.1.3/diagnose-by-sound.mcpb`
- Version: `0.1.3`
- Transport: `stdio`
- SHA-256: `0f5d0ec0773c2890d62b18addc98905b339ecc595184a194d0f27f3e8aaefc16`

## 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-10-25.

- **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: we found no dependency list to check in this bundle: either it runs a compiled binary, whose bundled manifests we do not read, or none of the package.json, requirements.txt, pyproject.toml or uv.lock files it ships for its runtime declares a dependency we can read (a requirements.txt that only points at a setup.py project, a local path, or a nested requirements file we cannot follow counts as none).
  - Install-script risk not yet assessed.
  - Dependency health could not be checked: we found no dependency list to check in this bundle: either it runs a compiled binary, whose bundled manifests we do not read, or none of the package.json, requirements.txt, pyproject.toml or uv.lock files it ships for its runtime declares a dependency we can read (a requirements.txt that only points at a setup.py project, a local path, or a nested requirements file we cannot follow counts as none).
- **Provenance & Transparency**: 32/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - License check failed: no license is declared.
  - Actively maintained (last published 4 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 83/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 1906 tokens (~112/item across 17 items; 17 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 97/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 90% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 17 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 18 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 20/100
  - Spec-recency check failed: implements MCP spec 2024-11-05; the latest is 2026-07-28.

**Unverified: 2 categories.** Categories scored 0 because we could not verify them: 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.farssaadeldin7-ux/diagnose-by-sound MCP server?

io.github.farssaadeldin7-ux/diagnose-by-sound ships as an MCPB bundle, a single file you download and open in an MCP host that supports MCPB bundles, such as Claude Desktop. The host reads the launch command from the bundle's own manifest, so there is no command to copy. Before opening it, check the file's SHA-256 matches the one the MCP registry declares for it, 0f5d0ec0773c2890d62b18addc98905b339ecc595184a194d0f27f3e8aaefc16; the commands to do that are on this page. If it does not match, do not open it.

- Download bundle: `https://github.com/farssaadeldin7-ux/claude-plugin-suite/releases/download/mcpb-v0.1.3/diagnose-by-sound.mcpb`
- SHA-256: `0f5d0ec0773c2890d62b18addc98905b339ecc595184a194d0f27f3e8aaefc16`

### Verify on macOS / Linux

```bash
echo "0f5d0ec0773c2890d62b18addc98905b339ecc595184a194d0f27f3e8aaefc16  diagnose-by-sound.mcpb" | shasum -a 256 -c
```

### Verify on Windows (PowerShell)

```powershell
(Get-FileHash -Algorithm SHA256 .\diagnose-by-sound.mcpb).Hash -eq "0f5d0ec0773c2890d62b18addc98905b339ecc595184a194d0f27f3e8aaefc16"
```

## 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-10-21 (score 36)

First indexed and scored.

## MCP tools (17)

### `sound_vocabulary` (~84 tokens)

Return the controlled vocabulary for describing a vehicle noise: sound characters, pitch bands, rhythms, the conditions a noise occurs under, locations, and what it changes with. Call this before diagnose so the observation uses terms the matcher recognises.

Input parameters:

- `dimension` (string): Optional single dimension to return: character, pitch, rhythm, occurs_when, location, changes_with, severity.

### `describe_signature` (~71 tokens)

Look up one acoustic signature in full: why it happens, how to confirm it, the parts usually involved and the questions that separate it from lookalikes. Use after diagnose to go deeper on a candidate.

Input parameters:

- `signature_id` (string, required): Signature id from a diagnose result, e.g. "wheel-bearing".

### `list_signatures` (~61 tokens)

List the acoustic signatures this plugin knows about, optionally filtered by vehicle system (brakes, wheels, driveline, suspension, steering, engine, transmission, exhaust, cooling, fuel, hvac, accessories).

Input parameters:

- `system` (string): Optional system filter.

### `diagnose` (~221 tokens)

Rank likely causes for a vehicle noise from a structured description of it. Returns candidates with calibrated confidence, the questions that would most narrow the field, and a safety verdict. Use sound_vocabulary first. Requires a paid plan; counts against the monthly diagnosis quota.

Input parameters:

- `changes_with` (array): speed, rpm, load, brake, steering, temperature or none. The most diagnostic field.
- `character` (array): What it sounds like, e.g. ["grind","squeal"].
- `limit` (number): How many candidates to return. Default 5.
- `location` (array): Where it seems to come from.
- `occurs_when` (array): Conditions that reproduce it, e.g. ["braking","turning_left"].
- `pitch` (array): low, medium or high.
- `rhythm` (array): continuous, speed_linked, rpm_linked, intermittent, once_per_event, random.
- `system` (string): Optional: restrict to one vehicle system.
- `vehicle` (object): Optional vehicle context.

### `repair_plan` (~131 tokens)

Build an ordered confirmation-and-repair plan for a chosen candidate: the tests to run in order, what each result rules in or out, parts typically involved, and book labour hours. Requires a paid plan.

Input parameters:

- `also_consider` (array): Other candidate ids to keep on the table.
- `currency` (string): Currency code for the labour line, e.g. "NOK", "USD". Default USD.
- `labour_rate` (number): Optional shop rate per hour, used to cost the labour line.
- `signature_id` (string, required): The candidate to plan for, from a diagnose result.

### `save_case` (~122 tokens)

Save this diagnosis to the local case history on this machine, optionally with the confirmed outcome. Requires a paid plan. Nothing is sent to any server — the history stays on this computer.

Input parameters:

- `candidates` (array): The ranked candidates returned by diagnose.
- `chosen` (string): Signature id the technician acted on.
- `notes` (string)
- `observation` (object): The observation used for the diagnosis.
- `outcome` (string): What it actually turned out to be, once known.
- `vehicle` (object): make, model, year, mileage.

### `review_cases` (~116 tokens)

Search the local case history, or check what this shop has previously found for a given signature or vehicle. The best evidence available is what the same noise turned out to be last time. Requires a paid plan.

Input parameters:

- `case_id` (string): Fetch one case in full.
- `limit` (number): Default 20.
- `make` (string)
- `model` (string)
- `query` (string): Free-text search across saved cases.
- `signature_id` (string): Summarise prior outcomes for this signature.

### `record_outcome` (~83 tokens)

Record what a saved case actually turned out to be, once the repair is confirmed. This is what makes review_cases useful over time. Requires a paid plan.

Input parameters:

- `case_id` (string, required)
- `chosen` (string): Signature id that proved correct.
- `notes` (string)
- `outcome` (string, required): What was actually wrong and what fixed it.

### `frequency_bands` (~81 tokens)

The frequency-band families — where knocks, slaps, ticks, rattles, whines, bearings, belts, brakes, exhaust leaks and maskers sit in frequency and time, with their spectrogram signatures — plus the harmonic rule. Reference data only; order_match is what runs the arithmetic against a measurement. Every figure is a band, not a threshold.

### `capture_check` (~145 tokens)

Mechanical check of the described recording conditions against the capture rules: HVAC, radio, windows, phone mounting, whether the noise was actually reproduced. Findings with fixes; it has not heard the recording and judges nothing about its content. Open — a bad capture should be caught before anyone pays for anything.

Input parameters:

- `hvac_off` (boolean): Was the HVAC/blower off?
- `phone_mounted` (boolean): Was the phone mounted or rested, rather than handheld?
- `radio_off` (boolean): Was the audio system off?
- `reproduced_live` (boolean): Was the noise actually happening during the recording?
- `windows_closed` (boolean): Were the windows closed during the capture?

### `order_match` (~254 tokens)

Order arithmetic: tie a measured spectrogram line (Hz) or stripe rate (events/second) to the rotating parts it could be — crank, camshaft, firing rate, accessory pulley, wheel — from RPM, cylinder count, road speed and tyre circumference, with harmonics to order 6 and the working shown for every candidate. Arithmetic only: when several rates match, the elimination tests decide, not this tool. Requires a paid plan.

Input parameters:

- `cylinders` (number): Cylinder count, to compute the firing rate.
- `events_per_second` (number): A stripe/impact rate, per second.
- `measured_hz` (number): A spectrogram line, in Hz. Pass this or events_per_second.
- `pulley_ratio` (number): A specific accessory pulley ratio, if known. Otherwise the typical 2–3× alternator band is used.
- `rpm` (number): Engine RPM when the measurement was taken.
- `speed_kmh` (number): Road speed when the measurement was taken.
- `tolerance_pct` (number): Match tolerance. Default 10.
- `tyre_circumference_m` (number): Rolling circumference in metres. Defaults to 2.0 with the assumption stated.

### `elimination_plan` (~193 tokens)

The staged elimination protocol over recorded results: pass the tests already run with their outcomes (survives/gone) and get back what each result mechanically rules in, the derived side of the vehicle where the tables decide it, a conflict flag when results point both ways (usually two noises), and the ordered tests still worth running. Pass no results for the full protocol from the top. Table lookups only — the ear and the drive stay with the person. Requires a paid plan.

Input parameters:

- `results` (object): Test outcomes recorded so far, e.g. {"neutral_coast": "survives", "surface_change": "gone"}. Test ids: engine_off, idle_parked, rev_neutral, hvac_sweep, ac_toggle, neutral_coast, two_gears, surface_c…

### `license_status` (~50 tokens)

Check the Diagnose by Sound licence on this machine: plan, included capabilities, remaining quota and seat usage. Call this when a paid tool reports a licence problem, or when the user asks what their plan includes.

### `license_activate` (~67 tokens)

Store and activate a Diagnose by Sound licence key on this machine. Use when the user pastes a licence key, or after a purchase completes.

Input parameters:

- `license_key` (string, required): The licence key, e.g. PS-XXX-00000-00000-00000-0000

### `start_checkout` (~74 tokens)

Begin a Diagnose by Sound purchase. Returns a Stripe Checkout link. Call list_plans first if the user has not chosen a plan.

Input parameters:

- `email` (string): Email address for the receipt and licence.
- `plan` (string, required): Plan id: "pro" or "team". Use list_plans to see the options.

### `list_plans` (~24 tokens)

List the available Diagnose by Sound plans, prices and what each one includes.

### `billing_portal` (~30 tokens)

Open the Stripe billing portal to change plan, update the card, or cancel the Diagnose by Sound subscription.

## Diagnostics

Captured diagnostic sections: Provenance. The full working is on the page: https://verifymcp.io/servers/farssaadeldin7-ux-diagnose-by-sound/diagnose-by-sound#diagnostics

## Score history

- 2026-10-25: 36
- 2026-10-24: 36
- 2026-10-23: 36
- 2026-10-22: 36
- 2026-10-21: 36

## Common questions

### What is the io.github.farssaadeldin7-ux/diagnose-by-sound MCP server?

io.github.farssaadeldin7-ux/diagnose-by-sound is an MCP server listed in the public MCP registry as io.github.farssaadeldin7-ux/diagnose-by-sound. Turn a described vehicle noise into a ranked, testable differential diagnosis with a safety... This page covers its MCPB bundle (https://github.com/farssaadeldin7-ux/claude-plugin-suite/releases/download/mcpb-v0.1.3/diagnose-by-sound.mcpb).

### Is the io.github.farssaadeldin7-ux/diagnose-by-sound MCP server safe to use?

io.github.farssaadeldin7-ux/diagnose-by-sound scores 36 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.farssaadeldin7-ux/diagnose-by-sound MCP server expose?

io.github.farssaadeldin7-ux/diagnose-by-sound exposes 17 tools: sound_vocabulary, describe_signature, list_signatures, diagnose, repair_plan, and 12 more. Their descriptions and schemas cost roughly 1,807 tokens of context every time the server is loaded.

## Links

- Repository: https://github.com/farssaadeldin7-ux/claude-plugin-suite
- Changelog RSS feed: https://verifymcp.io/servers/farssaadeldin7-ux-diagnose-by-sound/diagnose-by-sound.xml
- Changelog JSON feed: https://verifymcp.io/servers/farssaadeldin7-ux-diagnose-by-sound/diagnose-by-sound.json
- HTML version of this page: https://verifymcp.io/servers/farssaadeldin7-ux-diagnose-by-sound/diagnose-by-sound