/skill

Laravel Plugin Discovery

Original skill by ECC. Credit to ECC for the source work and core process.

Use the LaraPlugins.io MCP server to find and review Laravel packages.

When to Use This Skill

Use this skill when the user wants to:

• Find a Laravel package for a feature
• Compare Laravel packages
• Check if a package is still maintained
• Check support for a Laravel or PHP version
• Review a package before adding it to a project
• Search for packages from a known vendor

Do not use this skill to install or change packages unless the user asks.

MCP Setup

The LaraPlugins MCP server must be set up first.

Add this entry under mcpServers in ~/.claude.json:

{
  "laraplugins": {
    "type": "http",
    "url": "https://laraplugins.io/mcp/plugins"
  }
}

The server does not need an API key.

If the tools are not available, tell the user that the LaraPlugins MCP server must be set up. Do not make up search results.

Tools

SearchPluginTool

Search for packages and filter the results.

Parameters:

Use only values allowed by the tool. Version values must be strings.

GetPluginDetailsTool

Get details for one Composer package.

Parameters:

A package name must include both the vendor and package parts. If the user gives only a short name, search for it first.

Process

1. Learn the Project Needs

Find out these facts when they matter:

• Needed feature
• Laravel version
• PHP version
• Any vendor choice
• Whether the package is for a live app

Use facts already given by the user. Ask only for missing facts that would change the result.

If the version is a full value such as 12.2, use the major Laravel value "12". For PHP 8.3.6, use "8.3".

2. Search for Packages

Use SearchPluginTool with clear search words.

Add Laravel and PHP filters when the user gives those versions. Use a health filter when the user asks for a safe choice.

Do not assume that one search finds every good package. Try a close search word if the first search is weak. For example, try both "auth" and "authentication".

Use page if the first page does not have enough useful results.

3. Review the Best Matches

Pick a small set of strong matches. Then use GetPluginDetailsTool for each one.

Check:

• Health score
• Last activity date
• Laravel support
• PHP support
• Vendor risk data
• Recent release history
• Package purpose

Do not rank a package from its name or search text alone.

4. Report the Result

For each package, state:

• What it does
• Why it may fit
• Health state
• Laravel and PHP support
• Any clear risk or missing fact

End with a clear choice when the data supports one. If there is no clear winner, explain the tradeoff in simple words.

Health Guide

A health score is only one signal. A healthy package can still be a poor fit. An unrated package is not always unsafe.

Key Rules

1. Match the exact Laravel and PHP versions used by the project.
2. Get package details before giving a firm choice.
3. Prefer active packages with recent releases for live apps.
4. Treat vendor risk data as a clue, not proof.
5. Do not claim that a package is secure based only on its health score.
6. Do not claim support for a version unless the tool reports it.
7. Say when data is missing, old, mixed, or unclear.
8. Check more than one package when the user asks for the best choice.
9. Do not install a package unless the user asks.
10. Do not call any service other than the set up LaraPlugins MCP tools.

Edge Cases

• No results: Remove one filter or try a close search word. Tell the user what changed.
• Too many results: Add Laravel, PHP, vendor, or health filters.
• Unknown project version: Search without that filter, but mark support as not checked.
• Unsupported version value: Tell the user that the tool cannot filter that version. Do not use the nearest version without saying so.
• Package not found: Search by short name or vendor before saying it does not exist.
• Conflicting data: Report the conflict. Do not guess.
• Old last activity: Warn the user even if the health label looks good.
• Unrated package: Get full details and avoid a firm choice if key facts are missing.
• Pre-release framework version: State that support may change. Use only the support data returned by the tool.
• Same package under a new name: Report both names if the tool shows the move. Do not treat them as two separate choices.

Concrete Example

User request:

Find a permissions package for Laravel 12 and PHP 8.3. I need a safe choice for a live app.

First search:

SearchPluginTool({
  text_search: "permission",
  health_score: "Healthy",
  laravel_compatibility: "12",
  php_compatibility: "8.3"
})

Then review the best matches:

GetPluginDetailsTool({
  package: "spatie/laravel-permission",
  include_versions: true
})

If there are other strong matches, review them too.

A good reply should look like this:

My first choice is package-a/name.

It fits the permissions need and the tool lists support for Laravel 12
and PHP 8.3. Its health state is Healthy, and it has recent releases.

Package-b/name may also work, but its last update is older. I would use
it only if you need a feature that package-a/name does not have.

The health score is not a security check. Review the package code,
open issues, and release notes before using it in a live app.

Replace the sample package names and claims with real tool results.

More Tool Examples

Search for healthy admin panel packages for Laravel 12:

SearchPluginTool({
  text_search: "admin panel",
  health_score: "Healthy",
  laravel_compatibility: "12"
})

Search for healthy packages from one vendor:

SearchPluginTool({
  vendor_filter: "spatie",
  health_score: "Healthy"
})

Get package details without full version history:

GetPluginDetailsTool({
  package: "spatie/laravel-permission",
  include_versions: false
})

Related Skills

• laravel-patterns: Laravel design patterns
• laravel-tdd: Test-driven Laravel work
• laravel-security: Laravel security checks
• documentation-lookup: General library docs lookup with Context7