Xenmark MCP server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| XENMARK_TOKEN | Yes | Your Xenmark Personal API token (created in Xenmark: profile → Account & Security → Connected apps → Connect an app → "Personal API token (Postman, GitHub)" → Generate). Keep it in the assistant's config only. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| xenmark_whoamiA | Identify the Xenmark account behind the configured token: user_id, display_name, company. Never returns e-mail, plan, billing or role. |
| xenmark_recent_activityA | The user's Xenmark notification inbox, newest first: new comments, replies, mentions and status changes on drawings the user is part of. Each row has actor_name, project_name, drawing_number, revision_label, comment_number, title, preview, mention_labels, old_status/new_status (status changes), read, created_at and a web_url deep link into Xenmark. Use web_url for links - never build Xenmark URLs. |
| xenmark_list_projectsC | Projects the user owns or is a member of: id, name, description, company_name, status (active/archived), my_role, created_at, updated_at, web_url. |
| xenmark_list_drawingsA | Drawings in one project: id, drawing_number, name, revision_count, created_at, web_url. Needs the project id from xenmark_list_projects or xenmark_find_drawing. |
| xenmark_list_revisionsA | Revisions of one drawing: id, revision_label, original_filename, size_bytes, content_type, created_at, web_url. Files themselves are never available. |
| xenmark_review_summaryA | Comment-status rollup for one or more revisions (up to 100): total_comments, open_count, progress_count, closed_count, last_activity_at per revision. Revisions the user cannot access are silently omitted. |
| xenmark_list_commentsC | Comments on one revision: id, comment_number (quote this to people), title, description, status, author_display_name, page, reply_count, annotation_count, web_url, plus a replies_preview of up to 3 replies and replies_truncated. |
| xenmark_list_repliesA | All replies on one comment, paginated: id, author_display_name, body, created_at, edited_at. |
| xenmark_find_drawingA | Find drawings by drawing number or name fragment across the user's projects (or within one project) and return their ids, project, revision_count and web_url. Use this when the user names a drawing rather than an id. Walks at most 20 projects and says so if truncated. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a distinct resource or action: identity, notifications, projects, drawings, revisions, comment rollup, comments, replies, and drawing search. The only potential overlap (list_drawings vs. find_drawing) is explicitly clarified by descriptions, so an agent can reliably choose the right tool.
All names use a consistent snake_case style with a uniform 'xenmark_' prefix, which makes them predictable and readable. However, the semantic pattern is slightly mixed: most follow list_<noun>, but there are also find_drawing, review_summary, recent_activity, and whoami, so it is not a strict verb_noun convention throughout.
Nine tools is well-scoped for a read-only data-access server covering projects, drawings, revisions, comments, and activity. Each tool earns its place without redundancy, and the set avoids the bloat that would come from exposing every possible field or operation separately.
The read surface is thorough: identity, activity, projects, drawings, revisions, comments, replies, and a review summary are all covered. However, write operations that are central to a review workflow—posting comments/replies, changing comment status, or marking activity read—are entirely absent, creating a notable lifecycle gap.