Most active commenters

    Show HN: Open-Source MCP Server for Context and AI Tools

    43 points apichar | 13 comments | 14 Mar 25 23:15 UTC | HN request time: 0.955s | source | bottom

    Large Language Models (LLMs) are powerful, but they’re limited by fixed context windows and outdated knowledge. What if your AI could access live search, structured data extraction, OCR, and more—all through a standardized interface?

    We built the JigsawStack MCP Server, an open-source implementation of the Model Context Protocol (MCP) that lets any AI model call external tools effortlessly.

    Here’s what it unlocks:

    - Web Search & Scraping: Fetch live information and extract structured data from web pages.

    - OCR & Structured Data Extraction: Process images, receipts, invoices, and handwritten text with high accuracy.

    - AI Translation: Translate text and documents while maintaining context. Image Generation: Generate images from text prompts in real-time.

    Instead of stuffing prompts with static data or building custom integrations, AI models can now query MCP servers on demand—extending memory, reducing token costs, and improving efficiency.

    Read the full breakdown here: https://jigsawstack.com/blog/jigsawstack-mcp-servers

    If you’re working on AI-powered applications, try it out and let us know how it works for you.

    1. johnjungles ◴[15 Mar 25 00:34 UTC] No.43368812[source]▶
    This is pretty cool!

    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!

    replies(2): >>43368967 #>>43369736 #
    2. pdf2calguy ◴[15 Mar 25 00:59 UTC] No.43368967[source]▶
    sweet product
    3. dlevine ◴[15 Mar 25 01:22 UTC] No.43369073[source]▶
    I have been playing around with MCP, and one of its current shortcomings is that it didn’t support OAuth. This means that credentials need to be hardcoded somewhere. Right now, it appears that a lot of MCP servers are run locally, but there is no reason they couldn’t be run as a service in the future.

    There is a draft specification for OAuth in MCP, and hopefully this is supported soon.

    replies(4): >>43369261 #>>43369600 #>>43370482 #>>43370490 #
    4. knowaveragejoe ◴[15 Mar 25 02:02 UTC] No.43369261[source]▶
    There are remotely run MCP server options out there, such as mcp.run and glama.ai
    5. socrateslee ◴[15 Mar 25 03:08 UTC] No.43369600[source]▶
    For the OAuth part, the access_token is all an MCP server needs. So users could do an OAuth Authorization like in the settings or by the chatbot, and let MCP servers handle the storage of the access_token.

    For remote MCP servers, storing access_token is a very common practice. For MCP servers hosted locally, how to deal with a bunch of secret keys is a problem.

    6. fudged71 ◴[15 Mar 25 03:15 UTC] No.43369658[source]▶
    Very cool.

    How does it work when multiple installed MCP servers have overlapping functionality? Are MCPs going to have competing prompts saying for example they’re the best to choose for OCR etc?

    replies(1): >>43370199 #
    7. mdaniel ◴[15 Mar 25 03:36 UTC] No.43369770[source]▶
    "Open-Source" under what license? https://github.com/JigsawStack/jigsawstack-mcp-server control-f "license"
    replies(1): >>43369814 #
    8. drdaeman ◴[15 Mar 25 03:46 UTC] No.43369814[source]▶
    Individual package.json files say ISC (e.g. https://github.com/JigsawStack/jigsawstack-mcp-server/blob/c...), although I've no idea whenever author mentioning the license name but not providing the full text of the license legally counts.
    9. jasonjmcghee ◴[15 Mar 25 05:25 UTC] No.43370199[source]▶
    Yes absolutely. And if you install an mcp server with a poorly written prompt, your sota llm might try to use it for everything. Prompt injection attacks will also be a thing. Depending on how this all plays out, we're in for interesting times.

    The number of threads of people asking how to permanently accept all tool use so they don't have to accept them manually...

    10. lifty ◴[15 Mar 25 06:23 UTC] No.43370439[source]▶
    Still waiting for someone to implement and MCP to LSP bridge.
    11. Nedomas ◴[15 Mar 25 06:32 UTC] No.43370482[source]▶
    There's open source package that allows delaying providing credentials to MCP server to runtime / via MCP tool call: https://github.com/supercorp-ai/superargs

    For hosted MCPs: https://supermachine.ai

    12. rguldener ◴[15 Mar 25 06:35 UTC] No.43370490[source]▶
    You could use Nango for the OAuth flow and then pass the user’s token to the MCP server: https://nango.dev/auth

    Free for OAuth with 400+ APIs & can be self-hosted

    (I am one of the founders)