linear-strict
Related Servers
Alternatives to linear-strict
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceEnables multiple AI agents to share, incrementally synchronize, and restore work context within a common scope using persistent tickets, immutable updates, and text artifacts.MIT
- AlicenseNot gradedqualityCmaintenanceEnables agentic co-authoring of feature specs, decomposition into architecture-validated tickets, and idempotent syncing to Linear as projects with epics, sub-issues, and dependencies.MIT
- AlicenseNot gradedqualityBmaintenanceEnables agents to manage an event-sourced, git-backed ticket store through MCP tools, supporting operations like ticket creation, claiming, and transitions.373 PyPI5Apache 2.0
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to manage Linear workspace resources such as issues, projects, teams, cycles, and comments via Streamable HTTP MCP, with LLM-optimized tools and batch operations.702 npmMIT
- FlicenseAqualityDmaintenanceEnables reading and managing Linear issues by human-readable ID, with tools for searching, creating, updating, commenting, and resolving teams, states, labels, and assignees by name.11-
- AlicenseNot gradedqualityBmaintenanceEnables managing Linear teams, projects, issues, and comments through GraphQL-backed MCP tools, including creating, updating, searching, listing, and archiving records.282 npmMIT
TDQS
Scored across 19 tools
The set is largely distinct and even deliberately splits near-twins (mark_notifications_read vs mark_principal_notifications_read, notifications vs get_principal_notifications) with explicit rationale. The one real risk is the set_state / set_status / set_fields triple, which share a prefix and could be mis-picked at a glance, though the descriptions clearly delimit each (content vs workflow state vs other fields).
Most tools follow a verb_noun snake_case pattern (list_issues, create_issue, set_status, mark_notifications_read) with consistent prefixes for related operations. Minor deviations exist (whoami, notifications as a bare noun, claim), but overall the convention is readable and predictable.
19 tools sits just above the well-scoped band, but the strict workflow governance (claim, check_claim, set_state, set_status, comment typing, principal-inbox separation) justifies most of them. Few tools appear redundant; the count is slightly heavy rather than bloated.
Issue lifecycle is well covered (create, read, list, field edits, state transitions, claims, comments, history) plus teams, projects, cycles, initiatives and notifications. Gaps are minor: no delete/archive, no single-team/user lookups, and no global search beyond list_issues filters.