Add getIssueTool for fetching Linear issues by ID

[LordZardeck]

• Introduced getIssueTool to retrieve details of a specific Linear issue using its ID.
• Updated package.json to use @modelcontextprotocol/sdk version 1.8.0.
• Added input validation with Zod schemas for the new tool.
• Adjusted server request handlers to include the new tool in the tools list.

This should fix #17 along with the fact that there many issues using this tool, which I suspect had something to do with an out-of-date @modelcontextprotocol/sdk package, and some incorrect response types for certain resources

---

Important

Add getIssueTool for fetching Linear issues by ID, update dependencies, and adjust server handlers.

• Behavior:
  • Adds getIssueTool in index.ts to fetch Linear issues by ID.
  • Updates server request handlers in index.ts to include getIssueTool.
• Validation:
  • Adds GetIssueArgsSchema in index.ts for input validation using Zod.
• Dependencies:
  • Updates @modelcontextprotocol/sdk to version 1.8.0 in package.json.

^{This description was created by for c5a29cb. It will automatically update as commits are pushed.}

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to c5a29cb in 2 minutes and 28 seconds

More details

• Looked at 191 lines of code in 2 files
• Skipped 1 files when reviewing.
• Skipped posting 8 drafted comments based on config settings.

1. index.ts:541

• Draft comment:
  getIssueTool is added correctly, but consider aligning its input schema description to match the style of other tools for consistency.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50%
  None

2. index.ts:831

• Draft comment:
  A commented out debug log 'Starting Linear MCP Server...' was removed. If no longer needed, consider removing such legacy comments for cleaner code.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

3. package.json:20

• Draft comment:
  Dependency @modelcontextprotocol/sdk is updated to 1.8.0 as required. Verify that all breaking changes in the new version are handled.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50%
  None

4. index.ts:1051

• Draft comment:
  The multiline template literal in the 'linear_get_issue' handler may produce extra whitespace. Consider trimming or reformatting it for cleaner output.
• Reason this comment was not posted:
  Marked as duplicate.

5. index.ts:811

• Draft comment:
  The log statement for server startup is commented out. Consider using a configurable logging mechanism rather than disabling the log entirely.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

6. index.ts:836

• Draft comment:
  Default capabilities (e.g., prompts, resources with templates/read) were removed. Ensure this change is intentional as it may impact client operations relying on these defaults.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

7. index.ts:925

• Draft comment:
  The ListResourcesRequestSchema handler now returns an empty array. Verify that overriding the previous implementation (which returned linearClient.listIssues()) is intentional.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
  The comment asks the author to "verify" their intention, which is explicitly called out as a type of comment to avoid in the rules. The comment is speculative and doesn't point out a clear issue - it just asks if the change was intentional. Additionally, there could be valid reasons for this change that we don't understand without more context.
  Maybe this is actually a bug - returning an empty array instead of the issues could break functionality. Should I keep the comment to prevent a potential bug?
  Even if it might be a bug, the comment as written doesn't clearly state that. It just asks for verification, which violates the rules. If there was strong evidence this would break something, the comment should directly state the issue.
  The comment should be deleted because it asks for verification rather than stating a clear issue, and we don't have strong evidence that the change is incorrect.

8. package.json:20

• Draft comment:
  Pinning '@modelcontextprotocol/sdk' to '1.8.0' may prevent automatic patch/minor updates. Consider using a semver range (e.g., '^1.8.0') if that aligns with your update strategy.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
  The rules explicitly state "Do NOT comment on dependency changes, library versions that you don't recognize, or anything else related to dependencies." This is exactly the type of comment we should remove - it's about dependency versioning strategy. The author likely had a specific reason for pinning this version.
  The comment does raise a valid point about consistency in versioning strategy across dependencies. Maybe there's a good technical reason to keep this warning?
  While the comment may be technically valid, our rules are clear about not commenting on dependency-related changes. We should trust the author's judgment on version pinning.
  Delete this comment as it violates our rule about not commenting on dependency changes.

Workflow ID: wflow_byPlfTByS1Tf3hYU

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

The template literal in linear_get_issue handler has extra indentations. Consider using a trimmed or single-line approach to avoid unwanted whitespace in the output.

[ellipsis-dev]

Multiple registrations for ListResourcesRequestSchema exist. Ensure that the intended handler isn’t unintentionally overwritten.