实测可用开发和代码数据库和数据
Vinktar
Error tracking for small teams and their coding agents.
https://mcp.vinktar.com/mcpclaude mcp add --transport http mcp https://mcp.vinktar.com/mcpCursor 等客户端的配置
{
"mcpServers": {
"mcp": {
"type": "http",
"url": "https://mcp.vinktar.com/mcp"
}
}
}要注意
有会改数据的工具:9 个
服务方自己把这些工具标成了会删除或改写数据(destructiveHint),让智能体调用前先问你。
- 测试结果
- 实测可用:握手成功
- 工具
- 31 个工具
- 握手用时
- 2.8 秒
- 传输方式
- streamable-http · 2025-06-18
- 测试时间
- 2026 年 11 月 6 日
- 官方目录名称
com.vinktar/mcpv1.0.1- 登记于
- 2026 年 10 月 7 日
- 更新于
- 2026 年 10 月 7 日
最近 1 次测试
| 时间 | 结果 | 用时 |
|---|---|---|
| 2026-11-06 12:20 UTC | 握手成功 | 2.8 秒 |
它列出的 31 个工具
“只读”和“会改数据”是服务方自己标的。带下划线的参数是必填的。
add_panelAdd panel
Add a panel to a board. Each panel answers one question and reads at a glance: a number, a line or a bar. Build it from the structured types; `sql` is the last resort. Choose in this order: `funnel` for conversion through ordered events (viewed pricing → started checkout → paid), with a breakdown for conversion per segment (per shop, per plan): always a funnel, never a query or trend lines per step. `retention` for whether people come back. `trends` for everything that counts or sums events: `chart` "scalar" for one number (revenue, installs, failed charges; several numbers are several scalar panels, never one wide table), "line" for a metric over time, "bar" to compare segments over time, "hbar" to rank them, "share" for parts of a whole, "heatmap" for when in the week; set `display.format` to "currency" for money and "percent" for a rate. A series can carry its own `breakdown`, so one panel shows signups by plan beside checkouts by country; reach for that before SQL. A table only whe
dashboardIdnameprojectstypechartviewdisplaytrendsfunnelretentionquerysqlReasonissuestextbrowse_events只读Browse events
Raw events, newest first, under simple filters: event names, one user (distinctId), page search, property filters or a VinktarQL WHERE expression. Use it to see what one user did, or to inspect real payloads. Pass `eventId` instead to get that one event in full, every column and the whole payload. Windows longer than 30 days are narrowed to their last 30. For counts, use query_trends or run_sql instead of paging.
projectprojectseventIdnamesdistinctIdsearchfiltersexpressionlimitcursorlastfromtocheck_fixCheck fix
After a fix for an issue ships, start a server-side check of whether it comes back: occurrences on the fix release (or the next release seen) and later, against how many sessions reached that release, over a horizon of up to 14 days. It keeps running after this session. Read the result later with get_alert and the issueId. The result is never "fixed": it is recurred, no recurrence in N sessions, or not enough evidence.
issueIdreleaseenvironmenthorizonDaysminExposurecreate_alertCreate alert
Create an alert: a query (source events, errors or sql; measure count or unique_users; filters; an optional groupBy; a window in minutes), a condition (above or below a threshold, or changed by a percent against the window before, a week earlier or the trailing week) and who hears it (recipients among members, saved channels, the team by default). Each series is judged on its own and a series that fired stays quiet for one window. Examples: new issues = source errors, lifecycle first_seen, condition above, threshold 0. Users affected = source errors, measure unique_users, windowMinutes 60, above 100. Signups dropped = source events, event signup, condition changed, changeDirection down, changePercent 50, compare week. Orders stopped = source events, event order_placed, below 1. You cannot name a webhook, a URL or an outside address: a person adds those in Vinktar. Only create an alert when the user asked for one.
projectprojectsnamesourcemeasureeventsqleventFiltersgroupByenvironmentminLevelreleasetextContainsissueIdlifecyclewindowMinutesconditionthresholdchangePercentchangeDirectioncompareflooreveryMinutespendingForrecipientsnotifyTeamchannelslinkscreate_board会改数据Create board
Create an empty board in the workspace, to leave the user a view of what you found; fill it with add_panel, where each panel says which projects it reads. First decide what kind of board the request is, from the decision the user wants to make with it: "launch" when one feature or release just shipped: is it used, by whom, does it convert, did it break anything; "conversion" when a funnel someone cares about: where people drop and which segment converts; "growth" when the business at a glance: new people, active people, conversions and money over time; "engagement" when how much and how often people use the product, and whether they come back; "revenue" when money: how much, from whom, and the path to paying; "acquisition" when where people come from and which channels bring the ones who sign up; "reliability" when what is breaking and whether it hurts the flows that matter; "custom" when none of the above: a board shaped around one specific question. The result is a plan for that kind
namekindprojectprojectsdescriptionexpiresInDaysdefine_event会改数据Define event
Define an event in the project's tracking plan: what it means, its role, the properties it carries (type, unit, whether every send must include it, an example) and where the code sends it. Call it in the same step as adding or changing a track() call, before any data arrives; and for existing events once you have read the code that sends them. It takes effect at once, labelled as written by an agent, and the team can correct it in Vinktar. get_setup_status then reports defined events that never arrive and sends missing a required property. Conventions (get_install_guide with section "conventions" has them all): new event names and property keys are snake_case, object then past-tense action (signed_up, report_exported); a description is one sentence of at most 100 characters and a longer one is refused; an event already shipping under another spelling is defined as it is sent, never renamed unasked. Do not overwrite a description the team wrote unless the user asks. Setup call: never co
projecteventdescriptionrolecode_locationpropertiesdelete_board会改数据Delete board
Delete a board with its panels. Only when the user asked for it, or agreed when you proposed it; name the board before you do. A person can restore it in Vinktar from the boards page for 30 days.
dashboardIddelete_panel会改数据Delete panel
Remove a panel from its board. Only when the user asked for it, or agreed when you proposed it; say which panel before you do. The panel id is in get_board. A person can restore it in Vinktar from the boards page for 30 days.
panelIdget_alert只读Get alert
Read alerts and what they said. Pass alertId for one alert: its query and condition, whether it is on or snoozed, what its last check read per series, who hears it and what it said recently. issueId gives that issue's latest fix check (awaiting_release, watching, recurred, no_recurrence, not_enough_evidence or stopped, with exposure and recurrences on the fix release). Neither lists every alert in the project, what fired in the last 24 hours, and the saved channels an alert can post to.
alertIdissueIdprojectget_board只读Get board
Read a board: every panel computed over a window with the change against the previous period, as headline numbers. The quickest way to answer "how are we doing" in the terms the team already tracks. Each panel shows its id, for update_panel and delete_panel.
dashboardIdlastfromtoget_install_guide只读Get install guide
The step-by-step guide for setting Vinktar up in the app you are working in: which SDK fits the stack (with current versions), the recommended file layout and environment variables, defining the tracking plan as you add events, proving it with get_setup_status, and the handover telling the person where each variable goes. Call this first when asked to install, set up or audit Vinktar, and follow it. It ends with Vinktar's conventions (event and property naming, descriptions, how an event changes, releases and environments, identifying users and connecting the browser visit to the server); pass section "conventions" for those alone before adding or changing a track() call in an app that is already set up. It answers before sign-in too, and then starts with where the person signs in from each app. Setup call: never counted.
sectionget_issue只读Get issue
Everything needed to debug one error issue: what it is, its status and history, how often and for whom it happens in the window (by release, environment, browser, URL, tag), the latest occurrence's stack trace (source-mapped when available, each in-app frame linking to its file in the repository once the project's repository URL is set), breadcrumbs and request, and the product events that user sent in the 30 minutes before it.
issueIdlastfromtoget_project_keys只读Get project keys
The keys installing Vinktar needs: the project's public write key (VINKTAR_KEY) with the ingest host, the Sentry-compatible DSN and the Bugsnag-compatible endpoints, and whether a source-map upload key (VINKTAR_CLI_KEY, a secret) exists, with where a person creates one. The secret is never returned: tell the person to add it as a CI secret. Needs a read and write connection. Setup call: never counted.
projectget_schema只读Get schema
What a project tracks (or several, with `projects`, each under its own heading): event names with their volume over the last 30 days, the payload properties each event carries, user trait keys, and the columns and functions VinktarQL (run_sql) accepts. Call before any query so names are real. Pass `event` to see every property of one event, or `propertyKey` to see that property's most common values, which is how you find the exact spelling of one before filtering on it.
projectprojectseventpropertyKeypropertyScopesearchlimitget_setup_status只读Get setup status
Check a project's Vinktar install from the data that actually arrived: events and errors received, users identified, releases and environments tagged, source maps for the latest release, items the SDK dropped, and key events described. Each gap comes with the next step. Call it after installing, and again after each fix, until nothing is left to do. Setup call: never counted against the agent allowance.
projectget_start_status只读Check a started project
Whether events and errors have arrived for a project started with start_project, by its write key, and whether the person has claimed it yet. Call it after installing the SDK and sending a first event. Projects someone already claimed answer only after sign-in, through get_setup_status.
keylist_boards只读List boards
The boards whose panels read from a project, or from any of several with `projects`. A board shows what the team already decided matters; read one with get_board.
projectprojectslist_issue_occurrences只读List issue occurrences
Recent individual occurrences of one issue, newest first: when, which user and session, release, environment, page, browser and OS. Use it to spot a pattern (one browser, one release, one customer) or to pick a user or session to follow in browse_events.
issueIdlimitcursorlist_issues只读List issues
Error-tracking issues (errors grouped by fingerprint) for a project, or across several with `projects`, with occurrences and affected users inside the window. Default: open issues (unresolved + regressed) sorted by occurrences over the last 14 days. Follow up with get_issue for the stack trace.
projectprojectsstatuslevelenvironmentreleasesearchsortlimitcursorlastfromtolist_projects只读List projects
List the Vinktar projects this connection can read (a project is one app or site sending events and errors), with the workspace plan and what this connection is allowed to do. Call this first when you do not know the project handle.
query_funnel只读Query funnel
Conversion through an ordered sequence of events (e.g. view_pricing → start_checkout → purchase): how many entered, how many reached each step, where they dropped, how long converting took, optionally by segment.
projectprojectsstepsorderconversionWindowbreakdownfilterslastfromtoquery_retention只读Query retention
Cohort retention: users who did targetEvent in a period form a cohort, and the table shows what share of each cohort did returningEvent in each later period. Use it for "do people come back" and "did retention improve after the change".
projectprojectstargetEventreturningEventperiodperiodsfilterslastfromtoquery_trends只读Query trends
Metrics over time: event counts, unique users or sessions, the sum, average or p95 of a numeric property, optionally split by a property (one breakdown for every series, or each series by its own) and compared to the previous period. The workhorse for "how many / how much / is it growing" questions. interval "total" returns one de-duplicated number per series for the whole window.
projectprojectsseriesbreakdownsfiltersintervalcomparelastfromtorun_sql只读Run sql
Run a read-only VinktarQL SELECT over the project's `events` table, for anything query_trends, query_funnel and query_retention cannot express; start with those, since what they run is what a board panel should be. A ClickHouse-flavoured subset: WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, DISTINCT, IN, LIKE and allowlisted functions (count, uniq, sum, avg, quantile, countIf, toStartOfDay…); no joins, subqueries, CTEs or INTERVAL, so filter time as `timestamp > now() - 86400 * 7`. Payload properties are `properties.<key>`, user traits `user.<key>`. Tenant scoping and plan retention are applied automatically. Call get_schema first for columns, functions and property names, and aggregate in SQL rather than paging through raw rows.
projectprojectsquerylimitcursorset_project_notes会改数据Set project notes
Write the project's notes for AI agents: what the product does and for whom, the flows that matter (signup, activation, the paid action), what counts as an active user, and anything that makes the data easy to misread. Write them from the codebase during setup, in plain sentences, up to 2,000 characters; they replace the current notes, so read them in get_schema first and keep what the team wrote. Every later agent reads them before the data. Setup call: never counted.
projectnotesstart_projectStart a project without an account
Before the person has signed in to Vinktar: start a project for their app now, so setup can run and data can arrive before anyone makes an account. Returns the project's write key (public, safe in browser code) and a claim link that only the person should open: it signs them in, or makes them an account, and keeps the project with its data. Unclaimed, the project takes up to 10,000 events and is deleted with its data after 7 days. Only call it when the person has not signed in and the other tools ask for sign-in; once signed in, use list_projects and get_project_keys instead.
nameplatformupdate_alert会改数据Update alert
Change an alert from get_alert: any part of its query, condition, timing, recipients (workspace members) and channels (saved ids or "#name" in the connected Slack). Or hold its news with snoozeMinutes (0 ends a snooze; a week at most). Switching an alert off or deleting it is a person's, in Vinktar. Only change an alert when the user asked.
alertIdsnoozeMinutesnamesourcemeasureeventsqleventFiltersgroupByenvironmentminLevelreleasetextContainsissueIdlifecyclewindowMinutesconditionthresholdchangePercentchangeDirectioncompareflooreveryMinutespendingForrecipientsnotifyTeamchannelslinksupdate_board会改数据Update board
Rename a board, rewrite the line under its title, change when it deletes itself, or lay its panels out. A board is a grid: every row spans the full width, its panels share it (one to four) at one height, equally unless you give widths. Pass `rows` to set the layout outright, top to bottom, as rows of panel ids from get_board; panels you leave out keep their order after them. Or pass `arrange` to straighten the rows as they read now. Pass only what changes. Panels are changed with update_panel and delete_panel.
dashboardIdnamedescriptionexpiresInDaysrowsarrangeupdate_issue会改数据Update issue
Change an error issue's status or assignee: resolve it (optionally in the release that ships the fix, or in the next release when it has not shipped yet, so a later occurrence reopens it as a regression), ignore it, reopen it, or assign it to a teammate. Only act on an issue when the user asked you to.
issueIdstatusresolvedInReleaseresolvedInNextReleaseenvironmentassigneeupdate_panel会改数据Update panel
Change a panel on a board: its title, how it draws, its number format or what it shows. Pass only what changes; the rest stays as it is. The panel id is in get_board. To turn it into another type, pass `type` with the full spec for it, the same fields as add_panel. A changed panel is run and held to the same rules as add_panel before it is saved (structured types before SQL, one question per panel, the board's time range), and one that breaks them is refused with nothing changed.
panelIdnameprojectstypechartviewdisplaytrendsfunnelretentionquerysqlReasonissuestextwhats_changed只读What changed
Start here. One project's window, or several pooled with `projects` (every row then names its project), compared with the one before it, across analytics and errors: traffic (events, active users, sessions), the events that rose, fell, appeared or stopped, error volume, new, regressed and fastest-growing issues, and the releases that shipped, and what the project's alerts said. Each row names the tool to go deeper.
projectprojectslast
测试只做握手和列出工具,没有调用任何工具。名称和说明是登记的人写的,原样展示,我们没有核实。