# io.github.hmamut39/tewip (npm · tewip-ai)

Proves software work: triages failing tests, checks whether a test can fail, and reads migrations.

- Trust score: 70/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-16

## Components

- npm · `tewip-ai`: 70/100 (this document), [markdown](https://verifymcp.io/servers/hmamut39-tewip/tewip-ai.md), [page](https://verifymcp.io/servers/hmamut39-tewip/tewip-ai)

## Channel facts

- Registry: `npm`
- Package: `tewip-ai`
- Version: `0.58.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-10-16.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 31 of 92 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 48/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (Apache-2.0).
  - Actively maintained (last published 0 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 67/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 3370 tokens (~146/item across 23 items; 23 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 7/100
  - Stability observed for 2 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 99/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 98% 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 23 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 23 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.

## Install

### How do I install the io.github.hmamut39/tewip MCP server?

io.github.hmamut39/tewip runs locally as an npm package, launched with npx -y tewip-ai. 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 hmamut39-tewip -- npx -y tewip-ai
```

### Cursor

```json
{
  "mcpServers": {
    "hmamut39-tewip": {
      "command": "npx",
      "args": [
        "-y",
        "tewip-ai"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "hmamut39-tewip": {
      "command": "npx",
      "args": [
        "-y",
        "tewip-ai"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add hmamut39-tewip -- npx -y tewip-ai
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "hmamut39-tewip": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "tewip-ai"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add hmamut39-tewip --command npx --arg -y --arg tewip-ai
```

### Hermes

```yaml
mcp_servers:
  hmamut39-tewip:
    command: "npx"
    args: ["-y", "tewip-ai"]
```

### Netclaw

```json
{
  "McpServers": {
    "hmamut39-tewip": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "tewip-ai"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add hmamut39-tewip -t stdio -c npx -a -y tewip-ai
```

### Other

```json
{
  "mcpServers": {
    "hmamut39-tewip": {
      "command": "npx",
      "args": [
        "-y",
        "tewip-ai"
      ]
    }
  }
}
```

## 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-16 (score 70, +1)

- [functional improvement] Stability: unverified → 0.07
- [functional] Package version: 0.54.0 → 0.58.0

### 2026-10-14 (score 69, +30)

- [security improvement] Injection markers: unverified → pass
- [security] First check of Judged manipulation: pass
- [security] Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window).
- [functional improvement] Tool coverage: unverified → 100
- [functional improvement] MCP protocol: unverified → pass
- [functional] First check of Schema quality: fail
- [functional] First check of Destructive annotations: pass
- [functional] First check of Schema quality: fail
- [functional] First check of Tool coverage: 98
- [functional] First check of Schema quality: good

### 2026-10-12 (score 39)

First indexed and scored.

## MCP tools (23)

### `github_ci_report` (~105 tokens)

CI diagnosis for a pull request

Latest Tewip report from a GitHub repository's CI: which failing tests the change likely caused, why each failed, the next action, and any verified fix PR. Use for questions like "why did CI fail on my PR?".

Input parameters:

- `branch` (string): Branch name, when there is no PR
- `pr` (integer): Pull request number
- `repo` (string, required): owner/name, e.g. hmamut39/triage-agent-sandbox

### `list_datasets` (~23 tokens)

List datasets

Collected failure datasets on this machine, with size and latest run.

### `list_failed_runs` (~79 tokens)

List failed runs

Latest runs with failing tests: run id, time, branch and number of failing tests.

Input parameters:

- `dataset` (string): Dataset directory relative to the Tewip repo, e.g. "data/real/gutenberg-holdout". Default: data/ (what the reporter collected). See list_datasets.
- `limit` (integer)

### `triage_board` (~137 tokens)

SDET triage board

Every failing test of a run, grouped by next action (fix locator, stabilize, fix data, file bug, re-run environment, escalate), with confidence and evidence.

Input parameters:

- `ai` (boolean): Use the AI layer for failures the rules cannot decide (default true; needs OPENAI_API_KEY).
- `dataset` (string): Dataset directory relative to the Tewip repo, e.g. "data/real/gutenberg-holdout". Default: data/ (what the reporter collected). See list_datasets.
- `run` (string): Run id or a unique part of it. Default: the latest run with failures.

### `pr_impact` (~126 tokens)

Is this failure caused by the change?

Developer view of a run: which failures the change likely caused and which it probably did not, with the reason.

Input parameters:

- `ai` (boolean): Use the AI layer for failures the rules cannot decide (default true; needs OPENAI_API_KEY).
- `dataset` (string): Dataset directory relative to the Tewip repo, e.g. "data/real/gutenberg-holdout". Default: data/ (what the reporter collected). See list_datasets.
- `run` (string): Run id or a unique part of it. Default: the latest run with failures.

### `environment_report` (~129 tokens)

Environment failures

DevOps / SRE view of a run: environment failures grouped by the failing dependency, retry recovery, and one grouped alert text.

Input parameters:

- `ai` (boolean): Use the AI layer for failures the rules cannot decide (default true; needs OPENAI_API_KEY).
- `dataset` (string): Dataset directory relative to the Tewip repo, e.g. "data/real/gutenberg-holdout". Default: data/ (what the reporter collected). See list_datasets.
- `run` (string): Run id or a unique part of it. Default: the latest run with failures.

### `release_readiness` (~129 tokens)

Release readiness

Business / UAT view of a run in plain words: READY, WAIT or NOT READY, and which product areas are broken.

Input parameters:

- `ai` (boolean): Use the AI layer for failures the rules cannot decide (default true; needs OPENAI_API_KEY).
- `dataset` (string): Dataset directory relative to the Tewip repo, e.g. "data/real/gutenberg-holdout". Default: data/ (what the reporter collected). See list_datasets.
- `run` (string): Run id or a unique part of it. Default: the latest run with failures.

### `quality_report` (~109 tokens)

Engineering quality

Senior / principal engineer view over the whole dataset: flakiness hotspots, recurring root-cause patterns, test-design debt ranked by CI time lost.

Input parameters:

- `ai` (boolean): Use the AI layer for failures the rules cannot decide (default true; needs OPENAI_API_KEY).
- `dataset` (string): Dataset directory relative to the Tewip repo, e.g. "data/real/gutenberg-holdout". Default: data/ (what the reporter collected). See list_datasets.

### `architecture_report` (~108 tokens)

Architecture fragility

Architect view: fragile areas (main-branch bugs vs regressions caught in PRs), single commits that broke many suites, failing service dependencies.

Input parameters:

- `ai` (boolean): Use the AI layer for failures the rules cannot decide (default true; needs OPENAI_API_KEY).
- `dataset` (string): Dataset directory relative to the Tewip repo, e.g. "data/real/gutenberg-holdout". Default: data/ (what the reporter collected). See list_datasets.

### `risk_digest` (~106 tokens)

Risk digest

Lead / manager view: product areas whose failure rate grew between the first and second half of the data window, on the main branch.

Input parameters:

- `ai` (boolean): Use the AI layer for failures the rules cannot decide (default true; needs OPENAI_API_KEY).
- `dataset` (string): Dataset directory relative to the Tewip repo, e.g. "data/real/gutenberg-holdout". Default: data/ (what the reporter collected). See list_datasets.

### `explain_failure` (~152 tokens)

Explain one failing test

Everything the agent knows about one failing test: root cause, confidence and source, full evidence, history on this commit versus others, the next action and why.

Input parameters:

- `ai` (boolean): Use the AI layer for failures the rules cannot decide (default true; needs OPENAI_API_KEY).
- `dataset` (string): Dataset directory relative to the Tewip repo, e.g. "data/real/gutenberg-holdout". Default: data/ (what the reporter collected). See list_datasets.
- `run` (string): Run id or a unique part of it. Default: the latest run with failures.
- `test` (string, required): Part of the test name or file, case-insensitive

### `test_plan` (~180 tokens)

Write a test plan for a feature

A test plan grounded in a project on this machine: its existing tests (read in full where related), the code the feature lives in, an optional git change and live pages, and the failures Tewip diagnosed there before. Returns risks, prioritised scenarios, what is already covered and what to automate next. Saves the plan in the project's .tewip/plans (nothing else is written). Needs OPENAI_API_KEY; takes about a minute.

Input parameters:

- `diff` (string): A git range whose change to plan for, e.g. "main...HEAD"
- `feature` (string, required): What the feature does, in a sentence or two
- `project` (string, required): Absolute path of the project folder
- `urls` (array): Pages of the running app to read, e.g. ["http://localhost:3000/checkout"]

### `recall` (~136 tokens)

Has this happened here before?

What this project already concluded about a failure like this one: earlier failures that resemble it, what was decided, by which rule or which person, and the run each came from. Answers from records Tewip kept, never from a guess - and says plainly when nothing resembles it. Use before deciding what a failure means, and for questions like "have we seen this error before?".

Input parameters:

- `project` (string, required): Absolute path of the project folder
- `question` (string, required): An error message, or a question in plain words
- `test` (string): Narrow to one test id, when the question is about a particular test

### `trace_requirements` (~116 tokens)

Is this requirement covered, and is it passing?

Joins the plans Tewip wrote for a project to the tests that cover them and the runs that attempted them. A scenario counts as covered only when a real test can be named, and as passing only when a real run attempted it; everything else is reported as never run or not covered. Use for "are we ready to release?" and "what is not tested?".

Input parameters:

- `only` (string): Only plans whose title, ticket or feature contains this
- `project` (string, required): Absolute path of the project folder

### `next_action` (~113 tokens)

What should be done next about a goal?

Given a goal in plain words - "keep the checkout flow green" - says what Tewip would do next and why, from what it can actually see in the project. The order is fixed and published: a real bug first, then the environment, then flakiness, then anything failing it cannot explain, then a coverage gap. It decides only; it never changes a file.

Input parameters:

- `goal` (string, required): The goal, in plain words
- `project` (string, required): Absolute path of the project folder

### `vouch_tests` (~140 tokens)

Could these tests ever fail?

Reads test files and says, per test, whether a change to the code could break them: which compare no value, which leave an expectation unfinished, which compare something with itself, which catch and discard their own failure, and which never run. Where the checking happens in a helper it cannot follow it says so instead of accusing. Costs nothing and uses no model. Use it on tests that were just written - including tests you wrote yourself - before claiming a change is covered.

Input parameters:

- `paths` (array): Paths inside the project to read, relative to it. Defaults to the whole project.
- `project` (string, required): Absolute path of the project folder

### `prove_tests_catch_bugs` (~247 tokens)

Would the tests catch a bug here?

Breaks one source file in small, deliberate ways - a boundary moved by one, a condition inverted, an and that became an or, a returned flag flipped - runs the tests that reach that file, and reports every change none of them noticed. This is execution, not opinion: the line was covered, it just was not checked. Slow by nature (each change means a real test run, so expect minutes) and it needs a unit test framework. The file is always put back exactly as it was, and if the tests turn out not to load the file at all it says so instead of reporting false holes. Use it after writing or changing code, to find out whether the tests you are relying on would have stopped a mistake.

Input parameters:

- `budgetSeconds` (number): Total seconds to spend before stopping and saying how many were left (default 600)
- `file` (string, required): One source file, relative to the project, e.g. src/pricing.js
- `limit` (number): How many changes to try (default 6). More is a better answer and a longer wait.
- `project` (string, required): Absolute path of the project folder

### `is_the_work_done` (~182 tokens)

Is this work actually done?

One verdict on a change, from the layers that each have their own measured accuracy: is anything failing, is the changed code tested by something that really reaches it, can the tests in the change fail at all, would they catch a bug (only when prove is asked for, because that costs minutes), and is what was asked for covered. Answers ready, not ready, or cannot say - and cannot say is never rounded up to ready. Use it before claiming a piece of work is finished, including your own: a green test run is not the same as work that is done.

Input parameters:

- `diff` (string): A git range, e.g. main...HEAD (the default)
- `project` (string, required): Absolute path of the project folder
- `prove` (boolean): Also break the changed code and run the tests against it. Costs minutes.

### `which_tests_to_run` (~190 tokens)

Which tests could notice this change?

Narrows a test run to the tests that could notice a change, from facts in the source rather than a prediction: a test runs when it imports a changed file, reaches one through another module, is itself edited by the change, reads the repository at run time, or has failed recently. It refuses to narrow at all - and says why - when the change touches dependencies, build or test configuration, shared setup or fixtures, when the suite drives a browser, or when a changed file cannot be traced to any test. Use it to run the right tests quickly; what it leaves out, it leaves out for a stated reason.

Input parameters:

- `diff` (string): A git range, e.g. main...HEAD (the default)
- `files` (array): The changed files, when they do not come from a git range
- `project` (string, required): Absolute path of the project folder

### `what_will_this_migration_do` (~218 tokens)

What will this migration do to a live database?

Reads the migrations in a change and names what will happen when they run against a live database: a column dropped while the version still running keeps selecting it, a table dropped, an index built under a lock that blocks writes, a NOT NULL added to a populated table, a type change that rewrites it, a foreign key validated against every row, a data migration holding a transaction open, a step that cannot be undone. It also searches the repository for code that still uses the column being taken away. Reads SQL, Django, Rails and Alembic, judges only the forward path, and says plainly when it cannot read a migration. It does not know your table sizes, so it says what a statement does rather than how long it will take.

Input parameters:

- `diff` (string): A git range, e.g. main...HEAD (the default)
- `files` (array): Migration files to read, when they do not come from a git range
- `project` (string, required): Absolute path of the project folder

### `is_this_slower` (~196 tokens)

Is this change slower, and does it matter?

Judges a k6 load-test run, rather than restating its numbers. Two answers kept apart: whether the thresholds the team wrote in their own k6 script held, and whether this run is slower than the recorded baseline. The second is answered only from three or more baseline runs - below that it returns 'cannot say', because one run against one run cannot distinguish a regression from a busy machine, and a percentage printed without that distinction is how performance tooling gets ignored. It never predicts a duration, a capacity or a user impact, and it says what the run does not cover. Use it when asked whether a change made something slower.

Input parameters:

- `label` (string): Which load test this is, so two different suites do not become each other baseline
- `project` (string, required): Absolute path of the project folder
- `summary` (string, required): Path to the JSON from `k6 run --summary-export=summary.json`

### `accessibility_barriers` (~283 tokens)

Can everybody use this interface?

Accessibility barriers in a project's markup, each named against the WCAG 2.2 criterion a regulator would cite, with the evidence to check it. Two kinds of answer, kept apart on purpose: barriers that reading the markup proves (no alt attribute at all, a field with no label anywhere, a div that only a mouse can activate), and the ones only a person can settle, where something is written as an expression or a component and the markup cannot say. It also returns every criterion it did NOT check - contrast, focus order, whether alt text is any good - because those need a rendered page. Use it before shipping an interface, or when asked whether something is accessible; a clean result means these checks found nothing, never that the product is accessible. No browser, no network, no model.

Input parameters:

- `axeReport` (string): The JSON from an axe run OR a Lighthouse report, if the project has either - Lighthouse runs axe rules, so both work. It settles contrast, which reading markup cannot, and its findings are triaged ra…
- `path` (string): A file or directory inside the project to check instead of all of it
- `project` (string, required): Absolute path of the project folder

### `project_standards` (~166 tokens)

What are this project's own rules?

The house rules this team has written down in .tewip/standards/, and whether a change keeps them. Returns two things kept carefully apart: rules Tewip checks and enforces (a forbid or require pattern over a set of files), and guidance it can only carry - prose for the parts no pattern captures, which is passed on when something is written but never reported as verified. Use it before writing or changing code in somebody's project, so what you produce matches their conventions rather than yours.

Input parameters:

- `diff` (string): A git range whose changed files should be checked instead
- `files` (array): Files to check against the rules. Omit to list what the project has written.
- `project` (string, required): Absolute path of the project folder

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/hmamut39-tewip/tewip-ai#diagnostics

## Score history

- 2026-10-16: 70
- 2026-10-15: 69
- 2026-10-14: 69
- 2026-10-13: 39
- 2026-10-12: 39

## Common questions

### What is the io.github.hmamut39/tewip MCP server?

io.github.hmamut39/tewip is an MCP server listed in the public MCP registry as io.github.hmamut39/tewip. Proves software work: triages failing tests, checks whether a test can fail, and reads migrations. This page covers its npm package (tewip-ai).

### Is the io.github.hmamut39/tewip MCP server safe to use?

io.github.hmamut39/tewip scores 70 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 16 October 2026. It declares no install or post-install scripts. 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.hmamut39/tewip MCP server expose?

io.github.hmamut39/tewip exposes 23 tools: github_ci_report, list_datasets, list_failed_runs, triage_board, pr_impact, and 18 more. Their descriptions and schemas cost roughly 3,370 tokens of context every time the server is loaded.

### Is the io.github.hmamut39/tewip MCP server still maintained?

io.github.hmamut39/tewip is still listed as active in the MCP registry. We last reached this channel on 16 October 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.hmamut39/tewip MCP server under?

io.github.hmamut39/tewip declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/tewip-ai
- Socket report: https://socket.dev/npm/package/tewip-ai
- Repository: https://github.com/hmamut39/tewip
- Changelog RSS feed: https://verifymcp.io/servers/hmamut39-tewip/tewip-ai.xml
- Changelog JSON feed: https://verifymcp.io/servers/hmamut39-tewip/tewip-ai.json
- HTML version of this page: https://verifymcp.io/servers/hmamut39-tewip/tewip-ai