Static FE-BE contract-drift checker: finds frontend calls the backend does not expose. CLI + MCP.
Config is the same across clients — only the file and path differ.
{
"mcpServers": {
"io-github-nugehs-tieline": {
"command": "<see-readme>",
"args": []
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
Static FE-BE contract-drift checker: finds frontend calls the backend does not expose. CLI + MCP.
No automated test available for this server. Check the GitHub README for setup instructions.
Five weighted categories — click any category to see the underlying evidence.
No known CVEs.
No package registry to scan.
This server is missing a description. Tools and install config are also missing.If you've used it, help the community.
Add informationBe the first to review
Have you used this server?
Share your experience — it helps other developers decide.
Sign in to write a review.
Others in other
Pi Coding Agent extension (CLI-first) — routes bash/read/grep/find/ls through lean-ctx CLI for strong token savings. Optional MCP bridge can register advanced tools.
Apify MCP Server
97% token reduction for AI coding sessions — zero deps, 21 languages, MCP server
MCP proxy that compresses prose fields (tool descriptions, etc.) using caveman rules. Same accuracy, fewer context tokens.
MCP Security Weekly
Get CVE alerts and security updates for io.github.nugehs/tieline and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.
Static frontend↔backend contract-drift checker. Pact without writing a single contract test.

tieline reads the code you already wrote on both sides of an API boundary — the
HTTP calls your frontend makes and the routes your backend exposes — and tells you
where they disagree. No contract tests to author, no broker to run, no backend to
boot. It finishes in well under a second and is built to run in CI as a gate.
Delete the LLM and a developer still installs it.
tielineis a deterministic tool first; an agent reading its output is a bonus.
frontend code backend code
(axios, rtk-query, …) (express, nestjs, openapi, …)
│ │
client adapter server adapter
│ normalize ${id} :id {id} → {} │
└───────────────► join on (METHOD, path) ◄──────┘
│
✅ matched ❌ drift ⚠️ unverifiable 🟡 dead
Both sides are reduced to a canonical (METHOD, path) and joined. The matcher is
adapter-agnostic — any client adapter pairs with any server adapter, so the
same engine checks a React app against Express, an Angular app against Spring, or
anything against an OpenAPI spec.
| Result | Meaning |
|---|---|
| ✅ matched | FE call resolves to a real BE route |
| ❌ drift | FE call resolves but the BE has no such route/method — the bug bucket |
| ⚠️ unverifiable | FE url is built at runtime — reported, never guessed |
| 🟡 dead | BE route no resolvable FE call reaches (informational) |
These tools solve neighbouring problems — pick by what you have and what you want guaranteed.
| Tool | How it works | What it catches | What it needs | Reach for it when |
|---|---|---|---|---|
| tieline | Static analysis of FE call sites + BE route declarations, joined on (METHOD, path) | A frontend calling a route the backend doesn't expose (path/method drift), undocumented/phantom spec routes | Source code of both sides; nothing running, nothing authored | You want a sub-second CI gate with zero contract tests to write or maintain |
| Pact | Consumer-driven contract tests executed at runtime, shared via a broker | Request/response payload mismatches between specific consumer–provider pairs | Contract tests written on both sides, a Pact broker, provider verification builds | Independent teams need payload-level guarantees and a can-I-deploy workflow |
| openapi-diff | Diffs two OpenAPI documents | Breaking changes between two spec versions | Accurate specs for both versions; doesn't read source code | Your API surface is spec-first and you want to gate spec changes |
| Optic | Tracks your OpenAPI spec over time and diffs every change in CI | Breaking changes and style/standards violations in the spec's history | An OpenAPI spec kept in the repo | You govern an evolving spec and want each PR's API changes reviewed |
| Schemathesis | Property-based fuzzing of a running API |