Skip to content
Agentmart
Submit a tool

Tewip

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

Connector by hmamut39 · GitHub account verified by the MCP Registry

IndexedApache-2.0Local (stdio)
Write a review

Install

Works with Claude Code, Codex, VS Code, Cursor, Windsurf, Claude Desktop. Read the repository before you give any tool access to your data.

npx agentmarket install connector/hmamut39-tewip

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

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

Reviews

Write a review

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this server can do and what it asks for, from its tool list and install config. Checked Oct 25, 2026.

Tools
21 read · 2 write · 0 delete
Secrets
1 (API keys, tokens or passwords)
Install scripts
Not scanned yet
Runs as
Node.js package

Tools by what they do 23

Read from the source code; the running server may list different tools.

Read 21 · Look things up without changing anything.

  • accessibility_barriers
  • architecture_report
  • environment_report
  • explain_failure
  • github_ci_report
  • is_the_work_done
  • is_this_slower
  • list_datasets
  • list_failed_runs
  • next_action
  • pr_impact
  • project_standards
Show 9 more tools
  • quality_report
  • recall
  • release_readiness
  • risk_digest
  • trace_requirements
  • triage_board
  • vouch_tests
  • what_will_this_migration_do
  • which_tests_to_run

Write 2 · Create, change, send or run things.

  • prove_tests_catch_bugs
  • test_plan

Secrets and settings it asks for

Secrets: values you paste in that let it act as you.

  • OPENAI_API_KEY

Files it touches

  • Any path the agent passes to its tools

Tools (23)

Read from the source code; the running server may differ. Descriptions are the server’s own words; hidden characters are shown as [U+…].

  • accessibility_barriersCan everybody use this interface?read-only

    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 bef…

  • architecture_reportArchitecture fragilityread-only

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

  • environment_reportEnvironment failuresread-only

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

  • explain_failureExplain one failing testread-only

    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.

  • github_ci_reportCI diagnosis for a pull requestread-only

    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?".

  • is_the_work_doneIs this work actually done?read-only

    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.

  • is_this_slowerIs this change slower, and does it matter?read-only

    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 a…

  • list_datasetsList datasetsread-only

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

  • list_failed_runsList failed runsread-only

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

  • next_actionWhat should be done next about a goal?read-only

    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.

  • pr_impactIs this failure caused by the change?read-only

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

  • project_standardsWhat are this project's own rules?read-only

    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.

  • prove_tests_catch_bugsWould 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 co…

  • quality_reportEngineering qualityread-only

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

  • recallHas this happened here before?read-only

    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?".

Show 8 more tools
  • release_readinessRelease readinessread-only

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

  • risk_digestRisk digestread-only

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

  • test_planWrite 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.

  • trace_requirementsIs this requirement covered, and is it passing?read-only

    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?".

  • triage_boardSDET triage boardread-only

    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.

  • vouch_testsCould these tests ever fail?read-only

    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.

  • what_will_this_migration_doWhat will this migration do to a live database?read-only

    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…

  • which_tests_to_runWhich tests could notice this change?read-only

    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.

Signals

Stars
0
Forks
0
Open issues
2
Last commit
Oct 19, 2026 (9 days ago)
Last release
Oct 19, 2026 (9 days ago)

From GitHub (fetched Oct 24, 2026).

Details

Registry name
io.github.hmamut39/tewip
Version
0.70.16
Auth
API key
Packages
npm tewip-ai
License
Apache-2.0
Repository
github.com/hmamut39/tewip
First seen
Oct 24, 2026
Last checked
Oct 24, 2026
Source
Official MCP Registrygithub-graphql
Cite this page

Tewip MCP server. Agent Mart. https://agentmart.dev/connectors/hmamut39-tewip (last updated 2026-10-24)