Linear MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.4
Disambiguation4/5
Each tool has a distinct purpose: fetching a specific ticket, listing assigned issues, adding comments, creating issues, listing teams, and searching. The only potential overlap is between get_my_issues and search_issues, but the descriptions clearly separate the convenient personal view from general-purpose search.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as get_ticket, add_comment, and create_issue. The verbs are varied but appropriate, and the naming style is uniform throughout.
Tool Count5/5
With 6 tools, the server is well-scoped for its purpose. It includes the key operations for reading, creating, searching, and commenting on issues, plus team listing, without unnecessary bloat or missing core basics.
Completeness3/5
The server covers core read and create operations, comments, and search, but lacks update and delete for issues. This leaves a notable gap in the issue lifecycle, as agents cannot modify or close tickets, making it incomplete for comprehensive Linear workflow coverage.
Average 3.3/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone bears the burden of behavioral disclosure. It only claims 'search' (implying read-only) but does not describe matching behavior, sorting, pagination, or what fields are returned—significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded, and free of filler. However, 'various filters' is vague, and the sentence is efficient but lacks substance, so it does not reach a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is far too thin. It omits search behavior details, return format, and relationship to sibling tools, making the tool difficult to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The phrase 'various filters' adds no specific parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('Linear issues') with a general indication of filters, which helps distinguish from get_ticket (single ticket) and get_my_issues (personal scope). However, it does not enumerate filter types, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose search_issues over get_my_issues or get_ticket, nor any exclusions or prerequisites. The implied usage is broad, but the description offers no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely restates the action from the name, providing no details on authentication, side effects, idempotency, or return behavior. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is efficient but not notably exceptional; it simply states the action without adding context that would require more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks any mention of return values or post-conditions, and no output schema is present to fill that gap. While the parameter schema is complete, a create tool would benefit from stating what it returns (e.g., created issue object) or any prerequisites beyond the required schema fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptive comments, so the description itself adds no additional parameter meaning beyond what the schema already provides. Baseline score of 3 is appropriate; the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new Linear issue' uses a specific verb and resource, clearly indicating the action. It distinguishes well from sibling tools like get_ticket, search_issues, and add_comment, which are all read or comment operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—if you want to create a Linear issue, use this tool—but does not explicitly state when to use it versus alternatives or mention any exclusions. It lacks explicit guidance like 'use for new issues only' or 'prefer this over search_issues for creation.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get your assigned Linear issues' without mentioning read-only status, authentication requirements, pagination, sorting, or possible limitations. For a get operation, the behavior is mostly implied, but the lack of explicit detail about side effects or safety is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose. There is no redundant information or filler. It earns its place with clear, direct language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, so the description's brevity is somewhat appropriate. However, it does not mention what the returned data contains (e.g., issue titles, statuses, links) or any response format. Since the agent must select and invoke the tool correctly, the description is minimally adequate but leaves room for ambiguity about output structure and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter 'state' is fully documented in the schema with an enum and default value. The description adds no additional semantic context beyond the schema, which is acceptable given the schema's completeness. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get your assigned Linear issues' uses a specific verb ('Get') and resource ('assigned Linear issues'), clearly indicating it retrieves issues assigned to the current user. It distinguishes from siblings like 'search_issues' (which searches all issues) and 'get_ticket' (which retrieves one ticket), though not explicitly. Clarity is strong, but differentiation could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_issues' or 'get_ticket'. The description does not mention context, prerequisites, or exclusions. With sibling tools present, this lack of usage direction leaves the agent to infer the use case from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. However, it does not explain what 'available' means, what the response contains (e.g., team names, IDs, objects), or any potential edge cases. For a read operation, more detail about the returned data would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the core purpose with no fluff or redundancy. It is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too sparse to provide complete context. It does not mention the return format, whether it lists all teams or just the user's teams, or any other behavioral details that would help the agent use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the definition automatically deserves a baseline of 4. There is no parameter information to add, and the schema is empty, so the description is not expected to explain parameter syntax or semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'available Linear teams', making it obvious what the tool does. It also distinguishes itself from sibling tools like get_ticket and search_issues by focusing on teams rather than tickets or issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any mention of when not to use it. The description simply states the action without providing context about prerequisites or use cases, so the agent must infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the basic write action but omits any side effects, permission requirements, or return behavior, making it insufficiently transparent for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with no wasted words, immediately conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the simple schema is fully covered, the lack of an output schema and absence of any return-value or prerequisite information leaves the description incomplete for a tool that creates data. A bit more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (ticket_id with example, comment text), so the description adds no additional semantic value; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the target ('a comment to a Linear ticket'), which is specific and distinct from sibling tools like get_ticket or create_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding comments to existing tickets but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., ticket must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Get' clearly indicates a read operation, but no additional behavioral details (e.g., return format, error handling, rate limits) are disclosed. For a simple get-by-ID tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no nested objects), the description is sufficient to convey its core function. It could mention that the full ticket object is returned, but this is largely implied by 'Get' and the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the ticket_id parameter with an example. The description adds no new semantic information beyond what the schema already provides, making this a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (Get) and resource (Linear ticket by ID). It is easily distinguishable from siblings like get_my_issues, search_issues, and create_issue, which cover other retrieval and creation scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose implies usage when a specific ticket ID is known, but no explicit guidance is given about when to use this instead of search_issues or get_my_issues. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![linear-mcp-server-again MCP server](https://glama.ai/mcp/servers/larryhudson/linear-mcp-server-again/badges/card.svg)](https://glama.ai/mcp/servers/larryhudson/linear-mcp-server-again)

Score Badge

Copy to your README.md:

[![linear-mcp-server-again MCP server](https://glama.ai/mcp/servers/larryhudson/linear-mcp-server-again/badges/score.svg)](https://glama.ai/mcp/servers/larryhudson/linear-mcp-server-again)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/larryhudson/linear-mcp-server-again'

If you have feedback or need assistance with the MCP directory API, please join our Discord server