feat: integrate Sveltest testing patterns into MCP

[Vinay-Khanagavi]

• Add new get-sveltest-patterns tool for vitest-browser-svelte
• Include 6 Sveltest documentation sections with use cases
• Update svelte-task prompt with testing tool instructions
• Support pattern types: setup, component-testing, form-testing, locators, runes-testing, mocking, troubleshooting, best-practices
• Add optional component_type parameter for specific examples

Closes #103

[changeset-bot]

🦋 Changeset detected

Latest commit: f7f391f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/mcp	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@Vinay-Khanagavi is attempting to deploy a commit to the Svelte Team on Vercel.

A member of the Team first needs to authorize it.

[paoloricciuti]

Hey, thanks for this...however I think we would need a different approach:

1. copying the sveltest documentation in here would mean it could very easily get out of sync with the original source...maybe @spences10 could help us by providing some llms.txt and an endpoint to fetch the list here?
2. we should probably also add resources that point to those sections
3. rather than just returning docs, it would be good to integrate those with the same system we use for the autofixer: we ask the LLM for the code, and we do static analysis to verify the patterns of sveltest. I think we should probably use a different tool for this since it's very different from the svelte one

[Vinay-Khanagavi]

Thanks for the feedback @paoloricciuti — that makes sense! Keeping docs in sync would definitely be tricky.

okay cool, I’ll take help from @spences10 for setting up the llms.txt reference and endpoint. After that, I’ll add Sveltest as resources pointing to relevant sections and start working on a separate pattern validator (similar to svelte-autofixer) for static checks. Does that sound good?

[paoloricciuti]

Sure 😄

[spences10]

I made sveltest for my team and then used those use cases to make IDE rules so the gang can take those files for their preferred workspace:

Cursor: https://github.com/spences10/sveltest/blob/main/.cursor/rules/testing.mdc
Windsurf: https://github.com/spences10/sveltest/blob/main/.windsurf/rules/testing.md
CLAUDE.md: https://github.com/spences10/sveltest/blob/main/CLAUDE.md
Claude SKILL: https://github.com/spences10/sveltest/tree/main/.claude/skills/sveltest-helper

llms.txt is a overview of the site and it's contents, it's not going to be much use to a coding assistant

There is an llms.txt that's built from an API route: https://github.com/spences10/sveltest/blob/main/src/lib/server/llms.ts

The rules files should be enough to go off of

[paoloricciuti]

@spences10 do you think it would be possible to subdivide the rules into different endpoints and provide a list?

[spences10]

here you go: https://sveltest.dev/api/examples

[spences10]

also feel free to contribute to it

[Vinay-Khanagavi]

Thanks @spences10 for the API endpoint, looks cool.

From https://sveltest.dev/api/examples,
I see 7 testing scenario endpoints covering Button variants, Form validation, Modal states, CRUD & Locator patterns, Authentication, and Runes testing.

@paoloricciuti — I see two options:

1. Dynamic API Resources
   Create MCP resources for each endpoint (/api/examples/button-variants, etc.), keep everything in sync with Sveltest, and LLM can query specific scenarios

2. Existing Rules Files like using the CLAUDE.md or rules files from the repo, Ready for LLM use but static (needs periodic updates)

Any Suggestions !!!
Should I hold off on the pattern validator until the resources are set up? Or go with the 1st option... since it stays in sync automatically and fits the "resources" pattern you mentioned.