vynix-mcp-server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VYNIX_API_URL | No | Vynix API base URL (default https://www.vynix.in) | https://www.vynix.in |
| VYNIX_API_EMAIL | No | Email for authentication (alternative to token) | |
| VYNIX_API_TOKEN | No | API token generated from Vynix dashboard | |
| VYNIX_API_PASSWORD | No | Password for authentication (alternative to token) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsA | List the Vynix projects you own. |
| list_annotationsA | List a project’s annotations, optionally filtered by status, type, or priority. Start here with status "open" to see what needs fixing. |
| get_annotationA | Fetch one annotation with its full captured context: page, target element (selector, XPath, styles), surrounding DOM, and runtime diagnostics (console + network). |
| list_commentsA | Read the discussion thread on an annotation. |
| get_annotation_analysisA | Read the latest stored AI diagnosis for an annotation (root causes, confidence, suggested fix, and likely source files). Returns null when none has been generated yet; run diagnose_annotation to create one. |
| get_annotation_screenshotsA | Return the region screenshots attached to an annotation as viewable images, so you can see exactly what the reporter pointed at. |
| list_annotation_issuesA | List the tracker (GitHub) issues opened from an annotation, with each issue’s live state. Set refresh to reconcile against GitHub (open/closed + any linked pull request). |
| list_project_issuesA | List every tracker issue across a project, with an open/closed/agent summary. |
| generate_promptA | Render a ready-to-paste coding prompt for an annotation, formatted for a target assistant. A deterministic template (no AI spend); for a deeper analysis use diagnose_annotation. |
| get_metricsA | Overview of your projects: KPI counts, status breakdown, a daily time series, and recent activity. |
| list_membersA | List a project’s team members, including role and status. |
| get_activityA | Recent activity feed for a project (status changes, comments, issues, members). |
| update_annotation_statusA | Update an annotation’s status, e.g. to mark it in_progress or completed. |
| add_commentA | Add a comment to an annotation’s thread, e.g. to record what you changed. Notifies the team. |
| diagnose_annotationA | Run the AI Diagnosis Engine on an annotation: it analyses the captured page, element, DOM, and runtime errors to produce ranked root causes, a confidence score, a suggested fix, and the likely source files. Calls an AI provider (uses tokens / may cost money) and stores the result. Requires AI + diagnosis enabled by the workspace admin and a key set. |
| create_github_issueA | Create a GitHub issue from an annotation. Uses the project’s configured repo and assignee unless overridden. Embeds the generated AI prompt in the issue body. |
| create_share_linkA | Mint a read-only public review link for a project, so a stakeholder can review its annotations without an account. Reporter emails are hidden on shared views. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| fix_annotation | A guided workflow to take one annotation from report to fix using the captured context and the AI diagnosis. |
| critical_issues | Identify and rank critical or high-priority open issues for a project. |
| summarize_feedback | Generate a stakeholder-friendly summary of open feedback for a project. |
| jira_ready_tasks | Convert selected open annotations into engineering-ready implementation tasks. |
| release_notes | Build release notes from completed annotations and linked tracker issues. |
| group_by_severity | Create a severity matrix from open annotations in a project. |
| review_homepage | Analyze homepage-related annotations and recommend a fix sequence. |
| qa_report | Generate a QA report from open, review, and completed annotations. |
| accessibility_review | Summarize accessibility findings and next actions for compliance readiness. |
| client_comments_summary | Summarize annotation comment threads into decisions and unresolved questions. |
| release_blockers | Identify unresolved issues likely to block release for a project. |
| sprint_report | Create a sprint status summary using annotation and issue activity. |
| engineering_tasks | Generate implementation tasks with acceptance criteria and risk notes. |
| regression_summary | Summarize likely regressions and recently re-opened defects. |
| pm_briefing | Create a PM-ready briefing on risk, progress, and decision points. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| server_metadata | Protocol-ready metadata describing this MCP server, auth, and transport modes. |
| tool_catalog | Quick reference for every tool, grouped by read and write behavior. |
| prompt_catalog | Prompt names and use cases for common Vynix workflows. |
| skill_catalog | Opinionated, complete workflows to run with Vynix data. |
| workflow_examples | Natural-language starter questions that map to production workflows. |
TDQS
Scored across 17 tools
Most tools are clearly distinct, but get_metrics and get_activity both surface recent activity, which could lead to misselection. Other tools like list_annotations vs get_annotation or get_annotation_analysis vs diagnose_annotation are clearly differentiated by read/action semantics.
All tool names follow a consistent verb_noun snake_case pattern (e.g., list_projects, update_annotation_status, diagnose_annotation). There is no mixing of conventions or vague verbs, making the set predictable and easy to navigate.
With 17 tools, the server is slightly above the ideal range, but each tool serves a distinct purpose in the annotation management, AI diagnosis, and GitHub integration workflow. The count feels justified rather than padded, though a few tools could potentially be consolidated.
The core lifecycle is well covered: listing and getting annotations, updating status, commenting, running/reading AI analysis, generating prompts, and creating GitHub issues. Missing operations like create/delete annotation or update/delete comments are minor gaps, likely because annotations are created externally or those actions are outside the server's scope.