Comments URL: https://news.ycombinator.com/item?id=46526572

Points: 10

# Comments: 3

Seems like though people want more integration to more local tools

Building a tool to supercharge your Cursor, Windsurf, Claude and other developer tools by connecting it to polished, high quality mcp servers for linear, slack, DBs, and other useful workflows.

I built https://skeet.build/mcp where anyone can try out mcp for cursor and dev tools.

We did this because of a painpoint I experienced as an engineer having to deal with crummy mcp setup, lack of support you have no idea how hard it is to set up SSE, deal with API keys and scope issues, and then to find things like the tool that you want isn’t even coded yet.

And so one of the areas we found it to be useful was to do the soft communications with tools like Jira linear slack - updating stakeholders and all that friction that engineers hate doing. Some other areas people use a lot of tools with sequential thinking

Mostly for workflows that I like:

* start a PR with a summary of what I just did * slack or comment to linear/Jira with a summary of what I pushed * pull this issue from sentry and fix it * Find a bug a create a linear issue to fix it * pull this linear issue and do a first pass * pull in this Notion doc with a PRD then create an API reference for it based on this code * Postgres or MySQL schemas for rapid model development

Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on

Lmk what you think!

Currently working on a desktop app so everything runs on a native Mac app!

I built https://skeet.build/mcp where anyone can try out mcp for cursor and dev tools.

We did this because of a painpoint I experienced as an engineer having to deal with crummy mcp setup, lack of support you have no idea how hard it is to set up SSE, deal with API keys and scope issues, and then to find things like the tool that you want isn’t even coded yet.

And so one of the areas we found it to be useful was to do the soft communications with tools like Jira linear slack - updating stakeholders and all that friction that engineers hate doing. Some other areas people use a lot of tools with sequential thinking

Mostly for workflows that I like:

* start a PR with a summary of what I just did * slack or comment to linear/Jira with a summary of what I pushed * pull this issue from sentry and fix it * Find a bug a create a linear issue to fix it * pull this linear issue and do a first pass * pull in this Notion doc with a PRD then create an API reference for it based on this code * Postgres or MySQL schemas for rapid model development

Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on

Lmk what you think!

[Sequential thinking](https://skeet.build/docs/integrations/sequentialthinking) - it’s like enabling thinking but without the 2x cost

[Memory](https://skeet.build/docs/integrations/memory) - I use this for repo / project specific prompts and workflows

[Linear](https://skeet.build/docs/integrations/linear)- be able to find and issue, create models a branch and do a first pass, update linear with a comment on progress

[github](https://skeet.build/docs/integrations/github) - create a PR with a summary of what o just did

[slack](https://skeet.build/docs/integrations/slack) - send a post to my teams channel with the linear and GitHub PR link with a summary for review

[Postgres](https://skeet.build/docs/integrations/postgres) / [redis](https://skeet.build/docs/integrations/redis) - connect my staging dbs and get my schema to create my models and for typing. Also use it to write tests or do quick one off queries to know the Redis json I just saved.

[Sentry](https://skeet.build/docs/integrations/sentry) - pull the issue and events and fix the issue, create bug tickets in linear / Jira

[Figma](https://skeet.build/docs/integrations/figma) - take a design and implement it in cursor by right clicking copying the link selection

[Opensearch](https://skeet.build/docs/integrations/opensearch) - query error logs when I’m fixing a bug

I built https://skeet.build/mcp where anyone can try out mcp for cursor and now OpenAI agents!

We did this because of a painpoint I experienced as an engineer having to deal with crummy mcp setup, lack of support and complexity trying to stand up your own.

Mostly for workflows like:

* start a PR with a summary of what I just did * slack or comment to linear/Jira with a summary of what I pushed * pull this issue from sentry and fix it * Find a bug a create a linear issue to fix it * pull this linear issue and do a first pass * pull in this Notion doc with a PRD then create an API reference for it based on this code * Postgres or MySQL schemas for rapid model development

Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on

Lmk what you think!

Also, right now engineers are hyper optimized in the code aspects but not thinking about the context into cursor and context out of cursor.

Like the amount of copy paste from Notion / JIRA / Sentry and the amount of output like summarizing the git commits and PRs, slack and other “over communication” you have to do these days. This is the area I think we can more easily automate away.

Have you also looked at mcp?

https://modelcontextprotocol.io/introduction

https://github.com/appcypher/awesome-mcp-servers

mcp.run glams.ai smithery.ai skeet.build (disclaimer: I built this one)

I too am working on effortless mcp servers for other developers using cursor and windsurf - there’s so much out there on mcp but turns out a lot of mcp servers don’t “just work”. A lot of other people have been porting APIs but actually you need to put a lot more thought into it because people don’t memorize uuids that are required to make api calls. Memory is a good approach, but afraid of the recall aspect and how that could potentially cause tool calls with bad inputs.

I built https://skeet.build where anyone can try out mcp for cursor and windsurf - we approached it with just brute force thoughtful design and a lot of trial and error.

We did this because of a painpoint I experienced as an engineer having to deal with Jira and Linear - updating slack and all that friction. I noticed I copy and paste a lot to cursor and so spent time building this app.

Mostly for workflows that I like:

* start a PR with a summary of what I just did * slack or comment to linear/Jira with a summary of what I pushed * pull this issue from sentry and fix it * Find a bug a create a linear issue to fix it * pull this linear issue and do a first pass * pull in this Notion doc with a PRD then create an API reference for it based on this code * Postgres or MySQL schemas for rapid model development

Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on

Lmk what you think!

1. Yes MCP is basically an api wrapper and function calling. However if you “just” port open api v3 specs then you get really weird results like (sorry I can’t move you linear ticket because you need the uuid of the todo and in progress workflow ids). Basically people don’t memorize uuids of the APIs. APIs weren’t designed for natural language so there’s a lot of work that needs to be put in in order for it to “just” work.

2. MCP is still in early days. There’s a lot of community mcp servers but more than half of them don’t actually work. Also you have to setup your own oauth, go get your own keys, read docs on auth because some authenticate at the app level not on user level and make sure the urls are correct. So even though everyone is posting about how easy it is to build your own mcp servers it’s actually a lot of friction.

3. SSE setup is trickier than you think. Remote mcp is something they’re working on still. SSE requires a lot of low level networking, load balancer time out tuning, heartbeats, etc to get things working reliably. Sure it works for your local machine for that 30 mins but to get it working scalably and reliably on cloud infrastructure is really hard and not yet proven out yet.

I build APIs for my day job and mcp isn’t the same as just porting over APIs.

I did this because of a painpoint I experienced as an engineer having to deal with Jira and Linear - updating slack and all that friction. I noticed I copy and paste a lot to cursor and so spent time building this app.

Mostly for workflows that I like:

• start a PR with a summary of what I just did - slack or comment to linear/Jira with a summary of what I pushed • connect to Postgres and build CRUD api from the table schema • pull this issue from sentry and fix it • pull this linear issue and do a first pass • pull in this Notion doc with a PRD then create an API reference for it based on this codebase, then create a new Notion page with the reference

Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on

Lmk what you think!

We did this because of a painpoint I experienced as an engineer having to deal with Jira and Linear - updating slack and all that friction. I noticed I copy and paste a lot to cursor and so spent time building this app.

Mostly for workflows that I like:

• start a PR with a summary of what I just did - slack or comment to linear/Jira with a summary of what I pushed • connect to Postgres and build CRUD api from the table schema • pull this issue from sentry and fix it • pull this linear issue and do a first pass • pull in this Notion doc with a PRD then create an API reference for it based on this codebase, then create a new Notion page with the reference

Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on

Lmk what you think!

We just make it a highly reliable, easy to use, after committing - add a comment with a summary to that Jira/linear issue. Start a PR in GitHub and assign x, update the slack channel with an update.

In order to get this it wasn’t about porting APIs to mcp. It was thoughtfully designing and optimizing for these workflows. Also quality and polish where the calls are highly reliable - required lower level networking optimizations, sessions, etc to make to work smoothly.

But yes, also part of the frictionless experience was, just oauth.