Skip to main content
Glama
rahulparathy

SaaS Puppy MCP

SaaS Puppy MCP

Let your AI assistant look things up in SaaS Puppy, a directory of free-tier developer tools.

Ask it about one tool, or have it compare two or three. For each one you get what the free plan includes, the good and bad points, and the catch, plus a link to the full listing.

  • No sign-up, no API key, no cost.

  • Read-only. It can look things up. It cannot change anything.

  • Works with Claude, ChatGPT, Cursor, VS Code, Claude Code and any other app that supports MCP.

What is MCP?

MCP (Model Context Protocol) is a standard way to plug extra abilities into an AI assistant. Think of it as a power adapter: once this one is plugged in, your assistant can check SaaS Puppy for you instead of guessing from memory.

Related MCP server: verified-ai-free-tiers

What can I ask?

After you connect it, ask in plain language:

  • "What does Neon's free plan include, and what's the catch?"

  • "Compare Supabase and Neon for a side project."

  • "Show me a few free hosting options."

  • "Show me a few free email tools and tell me which ones need a credit card."

  • "Is there a free open-source option for uptime monitoring?"

The assistant picks the right tool and shows you the answer. You never call the tools yourself.

Set it up

Pick the way that matches your app. The first is the easiest because there is nothing to install.

The easy way: use the web address

Use this address, with no authentication:

https://saaspuppy.com/MCP

App

What to do

Claude (web and desktop)

Settings, then Connectors, then add a custom connector. Paste the address and choose no authentication.

ChatGPT

Add a custom remote MCP connection (where your plan supports it). Paste the address and choose no authentication.

Cursor

Settings, then MCP, then add a remote server with the address.

Claude Code

Run claude mcp add --transport http saas-puppy https://saaspuppy.com/MCP

VS Code

See docs/clients.md.

More apps (Hermes Agent, OpenClaw and others) are in docs/clients.md. App menus change often, so if a step looks different, follow the app's own MCP help and use the address above.

The local way: run the package on your computer

Some apps only support local servers. For those, install Node.js (version 20 or newer), then add this to the app's MCP settings:

{
  "mcpServers": {
    "saas-puppy": {
      "command": "npx",
      "args": ["-y", "saas-puppy-mcp"]
    }
  }
}

For Claude Code: claude mcp add saas-puppy -- npx -y saas-puppy-mcp

Check that it works

On your computer, run:

npx -y saas-puppy-mcp --check

You should see:

Checking the SaaS Puppy MCP at https://saaspuppy.com/MCP

PASS  Connected to the directory.
PASS  Found both tools: list_tools and compare_tools.
PASS  Asked a test question and got an answer.

All good. Your AI app can use this server.

If a line says FAIL, it also tells you what to try next.

Questions

Is it really free? Yes. There is no account, key or limit you need to manage. The hosted address is shared, so it has fair-use limits and may slow down if someone sends too many requests.

Does it see my files or chats? No. It only receives the lookup your assistant sends (for example, "Neon") and returns an answer. It holds no keys, reads no files and has no analytics of its own.

Why won't it list every tool? On purpose. The full directory is on saaspuppy.com. The assistant can look up one tool, a few examples from one category, or compare two or three tools. It declines requests to dump or page through everything.

What does "temporarily unavailable" mean? The package could not reach saaspuppy.com. Wait a minute and ask again. If it keeps happening, run the check above.

Where does the data come from? From the live SaaS Puppy directory. Each answer includes the date the listing was last verified. Prices and limits change, so open the linked page before you rely on a number.

npx says "command not found". Install Node.js from nodejs.org (the LTS version is fine), then restart your app.

Something else is wrong. Open an issue and paste the output of --check.

The two tools

Tool

What it returns

list_tools

A short summary of one tool by exact name or slug, or up to three examples from one category. Can filter by free-forever, free-trial, open-source or self-hosted.

compare_tools

Side-by-side summaries for two or three tools in the same category.

Each summary has the tool's purpose, up to three good things and three bad things, the catch, a free-tier summary, pricing models, trial days, whether a card is required, the date it was last verified, and the SaaS Puppy page URL.


For developers

How it works

This package is a small proxy. It defines the two tools locally, with the same names, input schemas and instructions as the hosted public MCP, so clients and registries can list them without a network call. When a tool runs, the package forwards the request to the hosted endpoint and returns the answer.

  • No secrets and no database access. All data and all limits live on the SaaS Puppy server.

  • One source of truth. Listings, verification dates and rate limits come from the site, so the package never serves stale data.

  • Fail-soft. If the hosted endpoint is unreachable, tools return a plain error that points to saaspuppy.com instead of crashing the client.

  • Local guard. Bulk, wildcard and pagination requests are refused before they leave your machine.

Run modes

npx -y saas-puppy-mcp                     # stdio (default)
npx -y saas-puppy-mcp --http --port 8080  # Streamable HTTP at /mcp, health check at /healthz
npx -y saas-puppy-mcp --check             # self-test

The HTTP mode is stateless, so it runs behind any load balancer. A Dockerfile is included:

docker build -t saas-puppy-mcp .
docker run --rm -p 8080:8080 saas-puppy-mcp

Configuration

Setting

Flag

Environment variable

Default

Upstream public MCP

--endpoint

SAAS_PUPPY_MCP_URL

https://saaspuppy.com/MCP

Upstream timeout (ms)

--timeout

SAAS_PUPPY_MCP_TIMEOUT_MS

20000

HTTP port (with --http)

--port

PORT

8080

HTTP bind address

--host

none

0.0.0.0

The upstream address must use https. Plain http is accepted only for localhost, for development.

Develop

npm install
npm run check     # typecheck, build and test in one go

The tests run a mock of the hosted endpoint, so they need no network.

File

Purpose

src/server.ts

Builds the MCP server and registers the two tools.

src/tools.ts

Tool names, descriptions and input schemas.

src/lookup.ts

Local copy of the bulk-request guard.

src/remote.ts

Client for the hosted endpoint, with reconnect and timeout.

src/http.ts

Stateless Streamable HTTP server.

src/check.ts

The --check self-test.

src/cli.ts

Command-line entry point.

See CONTRIBUTING.md to send a change.

Publishing

Maintainers: docs/launch-guide.md is a step-by-step launch checklist in plain English, and docs/publishing.md has the registry details.

License

MIT. SaaS Puppy listing data belongs to SaaS Puppy and is served under the terms at saaspuppy.com.

Available Tools

2 tools
compare_toolsCompare tool summariesA
Read-onlyIdempotent
Inspect

Compare short purpose, quota, pros, cons and catch summaries for two or three tools in one category; full details remain on SaaS Puppy.

NameRequiredDescriptionDefault
slugsYesTwo or three tool slugs from the same category.

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, closed-world behavior, so the bar is lower. The description still adds real value by disclosing that results are short summaries and that full details live elsewhere, which sets expectations for a deliberately truncated output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that enumerates exactly which summary fields are compared and closes with the scope limit. Nothing is wasted or buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter, no output schema, and full annotation coverage, the description supplies what's needed: which summary fields come back and that detail is intentionally shallow. It lacks only guidance on mismatched-category slugs or result ordering, which is minor for a read-only comparator.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single slugs parameter already documents the 2-3 item bound and the same-category constraint. The description's 'two or three tools in one category' restates the schema rather than adding format, ordering, or error-handling semantics, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (compare) and resource (short summaries of purpose, quota, pros, cons, catch) for two or three tools, which is clearly distinct from the sibling list_tools. The 'full details remain on SaaS Puppy' clause sharpens the scope by signaling this is a condensed view, though it never names list_tools as the alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when this applies (two or three tools within one category) but never tells the agent when to pick it over list_tools or what to do if the tools span different categories. Usage is inferable rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_toolsSummarize a tool or categoryA
Read-onlyIdempotent
Inspect

Summarize one exact tool name or slug, or up to three examples from a specific category. No bulk exports, pagination or full records; visit SaaS Puppy for more.

NameRequiredDescriptionDefault
queryNoExact tool name or slug, for example “Neon” or “cloudflare-turnstile”.
categoryNoCategory to sample, for example “hosting”. Returns at most three examples.
pricing_modelsNoOptional filters: free-forever, free-trial, open-source, self-hosted.

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral context that is not covered by the annotations or schema. It defines the granularity of the output (a summary, maximum of three examples), the level of specificity required for the query (exact name/slug), and the data limitations (no full records, no pagination).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is extremely concise. Both sentences are highly information-dense and functional. The constraints and limitations are front-loaded, making the entire definition efficient and easy to digest.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given its simplicity and the coverage provided by the annotations (read-only, closed world), the description is highly complete for the intended use case. It clearly defines the scope and boundaries of the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema coverage is 100%, establishing a baseline of 3. The description does add useful semantic meaning by clarifying that 'query' requires an 'Exact tool name or slug,' which helps the agent understand the constraint applied to that parameter beyond its basic type definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the function: to summarize tool names or categories. It defines two specific usage modes: querying an 'exact tool name or slug,' or retrieving 'up to three examples from a specific category.' This is specific, but the name 'list_tools' is slightly broad for the act of 'summarizing,' preventing a score of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides excellent boundaries for usage by explicitly stating what the tool will NOT do: 'No bulk exports, pagination or full records.' This sets clear expectations and steers users away from incorrect use cases (e.g., attempting to dump a database).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedcompare_tools
    • First observedlist_tools

TDQS

A3.8/5.0

Scored across 2 tools

Disambiguation4/5

list_tools and compare_tools have clearly different intents: one surfaces names/examples, the other produces a structured comparison. The boundary is understandable, though both operate on the same narrow data and could blur if a user wants both listing and comparison in one step.

Naming Consistency5/5

Both tools follow a clean verb_noun snake_case pattern (list_tools, compare_tools). With only two tools, the convention is fully consistent and predictable.

Tool Count3/5

Two tools is thin for a SaaS tool directory/comparison server; the surface feels like a minimal preview rather than a usable toolkit. It is not egregiously over-scoped, but the small count limits what an agent can accomplish without leaving the MCP.

Completeness2/5

There is no way to retrieve full tool records, search by name or use case, or enumerate categories systematically—list_tools explicitly refuses bulk exports and pagination. The server depends on external browsing for detailed data, leaving significant gaps for an agent trying to answer tool-selection questions end-to-end.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    A
    maintenance
    Search and compare free tiers, credits, and pricing changes across 1,500+ developer tools. 8 MCP tools for infrastructure decisions, cost estimation, and vendor comparison.
    4
    6 npm
    24
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI assistants to look up, filter, and shortlist 221 curated AI tools by industry, department, pricing tier, or free-tier availability over remote Streamable HTTP without authentication.
    MIT