Linear MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources and actions, but there is some overlap between linear_create_issue and linear_create_issues, and between linear_delete_issue and linear_delete_issues, which could cause confusion about when to use the singular vs. plural versions. The descriptions clarify the bulk operations, but the naming similarity still creates minor ambiguity.
Naming Consistency5/5
All tools follow a consistent snake_case naming pattern with a 'linear_' prefix and clear verb_noun structure (e.g., linear_create_issue, linear_search_issues). The naming is highly predictable and uniform across all 13 tools, making it easy for agents to understand and use them.
Tool Count5/5
With 13 tools, the server is well-scoped for managing Linear issues, projects, teams, and users, covering core operations like CRUD, search, and bulk actions. Each tool appears to earn its place without feeling bloated or insufficient for the domain of project management and issue tracking.
Completeness4/5
The toolset provides strong coverage for issue and project management, including CRUD operations, search, and bulk actions, with no major dead ends. However, there are minor gaps, such as missing update operations for projects or teams, and no tools for managing issue comments or attachments, which could limit some workflows.
Average 2.9/5 across 13 of 13 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 provided, the description carries the full burden of behavioral disclosure. It states 'Create a new issue' but doesn't mention whether this requires authentication, what permissions are needed, if it's idempotent, what happens on failure, or the typical response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, clear sentence with zero waste—it directly states the tool's action without unnecessary elaboration. It's appropriately sized and front-loaded, making it easy to parse quickly.
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?
For a mutation tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't cover authentication requirements, error handling, or return values, and it fails to differentiate from sibling tools. Given the complexity and lack of structured data, more context is needed for effective use.
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 schema already documents all 9 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters (e.g., teamId vs. projectId) or usage tips. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Create') and resource ('new issue in Linear'), which clarifies the basic purpose. However, it doesn't differentiate this tool from sibling tools like 'linear_create_issues' or 'linear_create_project_with_issues', leaving ambiguity about when to use this single-issue creation tool versus batch alternatives.
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 'linear_create_issues' (for bulk creation) or 'linear_create_project_with_issues' (for project-linked creation). The description lacks any context about prerequisites, such as authentication or team setup, or when this tool is preferred over siblings.
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 states it 'gets' information, implying a read-only operation, but doesn't clarify permissions needed, error handling, rate limits, or response format. This leaves significant gaps for a tool with no annotation coverage.
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 extremely concise at three words, with no wasted language. It's front-loaded with the core action, making it easy to parse quickly. This efficiency is appropriate for a simple 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 no annotations and no output schema, the description is incomplete. It doesn't explain what project information is returned, how errors are handled, or any behavioral traits. For a tool with minimal structured data, the description should provide more context to compensate.
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 has 100% description coverage, with the 'id' parameter documented as 'Project identifier'. The description adds no additional meaning beyond this, as it doesn't specify format or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get project information' clearly states the verb ('Get') and resource ('project information'), making the purpose understandable. However, it lacks specificity about what information is retrieved and doesn't differentiate from sibling tools like linear_search_projects, which suggests a broader search capability.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like linear_search_projects available, there's no indication whether this is for retrieving a single project by ID or if it should be preferred over search tools in specific contexts.
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 provided, the description carries full burden for behavioral disclosure. It states this 'initializes' an OAuth flow but doesn't explain what that means operationally - whether this launches a browser, returns a URL, requires user interaction, or handles token storage. For an authentication tool with security implications, this lack of behavioral detail is a significant 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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a straightforward authentication initialization tool and gets directly to the point.
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?
For an OAuth authentication tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (authorization URL, token, etc.), what the expected workflow is, or how it integrates with the callback sibling. The agent lacks critical context about how to properly use this security-sensitive tool.
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%, with all three parameters clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured schema fields, so it meets but doesn't exceed the baseline expectation when schema coverage is complete.
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 clearly states the action ('Initialize OAuth flow') and the target service ('with Linear'), providing a specific verb+resource combination. However, it doesn't differentiate from its sibling 'linear_auth_callback', which appears to handle the callback portion of the same OAuth flow, leaving room for potential confusion about when to use each tool.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing OAuth credentials), when this should be called in an authentication workflow, or how it relates to 'linear_auth_callback'. The agent receives no usage context beyond the basic purpose.
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 full burden but only states 'Handle OAuth callback' without disclosing behavioral traits. It doesn't explain what 'handle' entails (e.g., token exchange, error handling, persistence), security implications, rate limits, or side effects. This leaves critical gaps for an OAuth-related 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 extremely concise with just two words, front-loaded and zero waste. It directly states the tool's role without unnecessary elaboration, making it efficient for an agent to parse.
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 complexity of OAuth callbacks (involving authentication flows, token management, and potential errors), the description is incomplete. With no annotations, no output schema, and minimal behavioral disclosure, it fails to provide enough context for safe and effective use, especially compared to more detailed sibling tools.
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?
Schema description coverage is 100%, so the schema fully documents the single parameter 'code' as an OAuth authorization code. The description doesn't add any param-specific details beyond what the schema provides, but with only one parameter, the baseline is high. No additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Handle OAuth callback' states a general purpose (handling OAuth callbacks) but is vague about what specific action it performs—it doesn't specify whether it validates, exchanges, or stores tokens. It distinguishes from siblings like 'linear_auth' (likely for initiating auth) by focusing on the callback, but lacks a clear verb+resource combination.
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. It doesn't mention prerequisites (e.g., after 'linear_auth'), exclusions, or how it relates to other auth or data tools in the sibling list. The agent must infer usage 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 burden. It states 'update' implying mutation but doesn't disclose behavioral traits such as required permissions, whether updates are atomic or partial, error handling for invalid IDs, rate limits, or response format. For a bulk mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence ('Update multiple issues at once') that is front-loaded and wastes no words. It directly conveys the core purpose without redundancy, earning a high score for conciseness.
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 tool's complexity (bulk mutation with nested objects), lack of annotations, no output schema, and incomplete parameter coverage, the description is inadequate. It doesn't address critical aspects like mutation effects, error handling, or usage context, making it incomplete for safe and effective agent use.
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 50% (2 parameters total, with 'issueIds' and 'update' described in schema). The description adds no parameter semantics beyond the schema, not explaining what 'update' entails or constraints like ID formats. With moderate schema coverage, the baseline is 3, as the description doesn't compensate for gaps but doesn't worsen understanding.
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 clearly states the action ('Update multiple issues at once'), specifying the verb 'update' and resource 'issues', with 'multiple' indicating bulk operation. It distinguishes from single-issue updates like 'linear_create_issue' but doesn't explicitly differentiate from other bulk operations like 'linear_create_issues' or 'linear_delete_issues', keeping it at 4 rather than 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), compare to single-issue updates, or specify scenarios like batch editing versus individual changes. With sibling tools like 'linear_update_issue' (implied) not listed, the lack of explicit alternatives or context lowers the score.
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 provided, the description carries full burden for behavioral disclosure. It states this creates multiple issues (implying a write/mutation operation) but doesn't address authentication requirements, rate limits, whether the operation is atomic (all-or-nothing), what happens on partial failures, or what the return format looks like. For a bulk creation tool with zero annotation coverage, this is insufficient.
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 perfectly concise at just 5 words, front-loading the essential information with zero waste. Every word earns its place by clearly communicating the core functionality without unnecessary elaboration.
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?
For a bulk creation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical behavioral aspects like authentication needs, error handling, performance implications of bulk operations, or what the tool returns. Given the complexity of bulk operations and lack of structured metadata, the description should provide more context.
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 schema already documents the single 'issues' parameter and its nested structure comprehensively. The description adds no additional parameter semantics beyond implying bulk capability ('multiple issues at once'), which is already evident from the array type in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the action ('create multiple issues at once') and identifies the resource ('issues'), making the purpose immediately understandable. However, it doesn't differentiate from its sibling 'linear_create_issue' which creates single issues, leaving some ambiguity about when to choose one over the other.
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?
The description provides no guidance on when to use this tool versus alternatives like 'linear_create_issue' for single issues or 'linear_create_project_with_issues' for project-based creation. There's no mention of prerequisites, performance considerations for bulk operations, or error handling for partial failures.
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. 'Delete an issue' implies a destructive, irreversible mutation, but it doesn't specify permissions required, confirmation steps, side effects (e.g., related data cleanup), or error handling. For a destructive tool with zero annotation coverage, this is a significant gap in transparency.
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 extremely concise at just three words ('Delete an issue'), with zero wasted language. It's front-loaded and gets straight to the point, making it easy for an agent to parse quickly. This is an example of efficient communication.
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 that this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or return values, which are critical for safe invocation. The high schema coverage helps with parameters, but overall context is lacking for a tool that performs deletions.
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 has 100% description coverage, with the 'id' parameter clearly documented as 'Issue identifier (e.g., ENG-123)'. The description adds no additional parameter information beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to since the schema is sufficient.
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 'Delete an issue' clearly states the action (delete) and target resource (issue). It's specific and unambiguous about what the tool does. However, it doesn't differentiate from its sibling 'linear_delete_issues' (plural), which appears to be a bulk deletion tool, so it misses the opportunity to clarify this distinction.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when deletion is appropriate, or how it differs from 'linear_delete_issues' for bulk operations. Without any usage context, the agent must infer everything from the tool name and schema.
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 provided, the description carries the full burden of behavioral disclosure. It states the action ('Delete') but fails to describe critical traits like permission requirements, whether deletions are permanent or reversible, rate limits, error handling, or what happens to associated data. For a destructive operation, this is a significant 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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.
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?
For a destructive tool with no annotations and no output schema, the description is inadequate. It doesn't cover behavioral aspects (e.g., permanence, permissions), usage context, or return values, leaving the agent with insufficient information to invoke it safely or effectively.
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%, with the parameter 'ids' documented as 'List of issue identifiers to delete'. The description adds no additional meaning beyond this, such as format examples or constraints on the array size. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the verb ('Delete') and resource ('multiple issues'), making the purpose unambiguous. However, it doesn't distinguish this tool from its sibling 'linear_delete_issue' (singular vs. plural), which would require explicit differentiation for a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'linear_delete_issue' (for single deletions) or other mutation tools. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with minimal context for decision-making.
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. While it mentions 'filtering and pagination', it doesn't describe important behavioral aspects like authentication requirements, rate limits, error conditions, or what the response format looks like. For a search tool with 8 parameters and no annotations, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core functionality. It's front-loaded with the essential information and contains no unnecessary words or redundancy.
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 tool's complexity (8 parameters, no annotations, no output schema), the description is insufficiently complete. While concise, it doesn't address important contextual aspects like authentication requirements, response format, error handling, or how this tool relates to sibling tools. For a search tool with multiple filtering options, 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 schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond the schema by mentioning 'filtering and pagination' which aligns with parameters like query, teamIds, assigneeIds, states, priority (filtering) and first, after, orderBy (pagination). However, it doesn't provide additional semantic context beyond what's already in the schema descriptions.
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 clearly states the verb ('Search') and resource ('issues'), making the purpose evident. It also mentions 'filtering and pagination' which adds specificity about functionality. However, it doesn't explicitly distinguish this tool from sibling search tools like 'linear_search_projects'.
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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when to choose this over other issue-related tools (like linear_get_teams or linear_bulk_update_issues) or how it differs from linear_search_projects. Usage context is implied but not stated.
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 states the tool searches for projects by name but doesn't reveal whether this is a read-only operation, if it requires authentication, what the return format looks like, or if there are rate limits. For a search tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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 extremely concise at just four words ('Search for projects by name'), with zero wasted language. It's front-loaded and efficiently communicates the core functionality without unnecessary elaboration, making it easy for an agent to parse quickly.
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 annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what the search returns (e.g., a list of projects, error handling), how results are formatted, or any prerequisites like authentication. For a search operation in a context with multiple similar tools, more contextual information is needed to guide the agent properly.
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 description mentions searching 'by name,' which aligns with the single parameter 'name' in the input schema. Since schema description coverage is 100% (the schema already describes the parameter as 'Project name to search for (exact match)'), the description adds minimal value beyond what's in the structured data. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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 clearly states the tool's purpose as 'Search for projects by name,' which specifies the verb (search), resource (projects), and search criteria (by name). However, it doesn't differentiate from sibling tools like 'linear_search_issues' or 'linear_get_project,' which reduces clarity about when to use this specific search tool versus alternatives.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'linear_search_issues' (for searching issues) and 'linear_get_project' (for retrieving a specific project), there's no indication of whether this tool is for fuzzy matching, exact matching, or broader project discovery. The lack of context leaves the agent guessing about appropriate usage scenarios.
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 provided, the description carries full burden for behavioral disclosure. It mentions the teamIds requirement constraint, but doesn't describe whether this is a write operation, what permissions are needed, if it's idempotent, or what happens on failure. For a creation tool with no annotation coverage, this is inadequate.
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 appropriately concise with two sentences that both add value. The first states the core purpose, the second provides critical parameter guidance. No wasted words, though it could be slightly more structured.
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?
For a creation tool with 2 complex nested parameters, no annotations, and no output schema, the description is minimally adequate. It covers the teamIds constraint well but misses behavioral aspects like mutation implications, error handling, and relationship between project and issues parameters.
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?
With only 50% schema description coverage, the description adds significant value by clarifying the teamIds requirement (array vs single value) and referencing linear_get_teams for obtaining IDs. This compensates well for the schema coverage gap, though it doesn't explain all parameter relationships.
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 clearly states the tool creates a new project with associated issues, which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like linear_create_issue or linear_create_issues, which also create issues but without projects.
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?
The description provides no guidance on when to use this tool versus alternatives like linear_create_issue (for single issues) or linear_create_issues (for bulk issues without projects). It mentions teamIds requirement but doesn't explain the broader context for choosing this tool.
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 provided, the description carries the full burden of behavioral disclosure. It states the tool 'Get all teams' but doesn't specify if this is a read-only operation, whether it requires authentication, how data is returned (e.g., pagination, format), or any rate limits. The description adds minimal behavioral context beyond the basic action.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word contributes to understanding the tool's purpose.
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 complexity of a data retrieval tool with no annotations and no output schema, the description is incomplete. It lacks information on authentication requirements, return format (e.g., list of teams with states/labels), error handling, or any limitations (e.g., maximum teams returned). For a tool that likely interacts with an API, this leaves significant gaps.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for zero parameters, as the description doesn't need to compensate for any gaps.
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 clearly states the verb 'Get' and the resource 'all teams with their states and labels', making the purpose specific and understandable. It distinguishes from siblings like linear_get_user or linear_get_project by specifying teams, though it doesn't explicitly contrast with other team-related tools (none exist in the sibling list).
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication via linear_auth), differentiate from search tools like linear_search_issues, or indicate if this is for listing all teams versus filtered queries. Usage is implied only by the tool name and description.
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 provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's likely safe and non-destructive, but doesn't mention authentication requirements, rate limits, or what specific user information is returned, which are critical for a tool interacting with user data.
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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
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 tool's purpose (retrieving user information), the description is incomplete. With no annotations and no output schema, it fails to specify what data is returned (e.g., user ID, email, name) or any behavioral constraints like authentication needs, leaving significant gaps for an agent to use it effectively.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but that's acceptable here. A baseline of 4 is appropriate as the schema fully handles the parameter semantics.
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 clearly states the verb ('Get') and resource ('current user information'), making the purpose understandable. However, it doesn't distinguish this tool from potential siblings like 'linear_get_project' or 'linear_get_teams' beyond the resource type, which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't clarify if this is for authentication purposes (vs. 'linear_auth') or for retrieving user-specific data in workflows, leaving the agent to infer usage context.
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 MCP server](https://glama.ai/mcp/servers/timottowitz/linear-mcp/badges/card.svg)](https://glama.ai/mcp/servers/timottowitz/linear-mcp)

Score Badge

Copy to your README.md:

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

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/timottowitz/linear-mcp'

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