MCP server aggregating developer infrastructure deals, free tiers, and startup programs
Scored across 5 tools
Tools target distinct actions: search_deals for discovery, compare_vendors for side-by-side, plan_stack for stack planning, track_changes for monitoring, get_referral_code for referrals. Minor overlap between search_deals and compare_vendors when checking free tiers, but descriptions clarify use cases.
All tools use snake_case with a consistent verb_noun pattern (compare_vendors, get_referral_code, plan_stack, search_deals, track_changes). No deviations.
Five tools is well-scoped for a deals/pricing intelligence server; each tool covers a distinct workflow without redundancy.
The surface covers discovery (search_deals), comparison (compare_vendors), monitoring (track_changes), planning (plan_stack), and referral lookup (get_referral_code), which are the core operations for this domain. No obvious gaps for a read-only deal aggregator.
Compare developer tools and services side by side — free tier limits, pricing tiers, and recent pricing changes. Use this when choosing between similar services (e.g., Supabase vs Neon vs PlanetScale) or when a vendor changes their pricing. Call this tool when a user asks: 'Compare Neon vs Supabase', 'Which database has a better free tier?'.
| Name | Required | Description | Default |
|---|---|---|---|
| vendors | Yes | 1 or 2 vendor names. 1 vendor = risk check. 2 vendors = side-by-side comparison. | |
| include_risk | No | Include risk assessment (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds context about what is compared (free tier, pricing tiers, changes) but does not disclose other behavioral traits like data sources or freshness. This is consistent with the get_calls calibration example where annotations lower the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, usage context, and example queries. No fluff or redundancy. The description is front-loaded with the action verb and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with fully documented parameters and annotations, the description covers purpose, usage, and examples. No output schema exists, but the description sufficiently conveys what the tool does without needing to explain return values. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'vendors' and 'include_risk' fully described. The tool description does not need to add parameter details; the schema carries the burden. The description does give usage examples that imply parameter use, but no additional syntax or semantic detail beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Compare developer tools and services side by side'. It lists concrete comparison dimensions (free tier limits, pricing tiers, recent pricing changes) and provides examples, making it distinct from all sibling tools which are unrelated (e.g., check_balance, leaderboard).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'Use this when choosing between similar services... or when a vendor changes their pricing.' It also gives example user queries. However, it does not mention any exclusions or alternatives, though none are needed given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the referral link we hold for a vendor, with the reader benefit and every restriction attached to it. We hold codes for a handful of vendors and earn a commission on them; /disclosure lists all of them.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor | Yes | Vendor name to get the referral code for (e.g. 'Railway') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read-only operation. The description adds that the tool holds codes for a limited set of vendors and earns commission, but doesn't disclose specifics like rate limits, pagination, or whether the code is returned as a link or a string. Given the annotations cover safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the primary purpose and then provides important context about the limited vendor list and the disclosure alternative. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description is quite complete. It covers what the tool does, the constraint on vendors, and points to an alternative for a full list. The only minor gap is the lack of explicit return format, but given the simplicity and no output schema, this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the 'vendor' parameter is well-described in the schema. The description adds that the vendor must be among those for which codes are held, but doesn't go beyond the schema's example. Since the schema does he heavy lifting, a baseline of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to look up the referral link held for a specific vendor. It specifies the resource (referral link) and the action (look up), and mentions the context of commissions and disclosure, which helps differentiate it from sibling tools like search_deals or compare_vendors. However, it doesn't explicitly compare itself to siblings, so it's slightly less than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: to retrieve a referral code for a vendor. It also implies that there is a curated list of vendors (only a handful) and points to /disclosure for a full list, which gives the agent an exclusion criterion. It does not explicitly say 'use this instead of X' but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan a technology stack with cost-optimized infrastructure choices. In recommend mode this returns, for each role, the set of offers whose terms we can stand behind today — deliberately not a single pick, because under every signal we record dozens of them tie. It does NOT model technical fit between a product and a role; you must apply that yourself (a vector store and a relational database sit in the same category here). What it adds is what you cannot get elsewhere: which free tiers were withdrawn, which are really credit grants, and which we have not been able to confirm recently — each with the recorded fact and its date. Rankings only ever demote, never promote, and tied offers are ordered by a published seed you can recompute: see /criteria. Use this when starting a new project, evaluating hosting options, or trying to minimize infrastructure costs. Call this tool when a user asks: 'What free tools can I use for a SaaS app?', 'Build me a stack under $50/month'.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | recommend: free-tier stack for a use case. estimate: free-tier status check. audit: risk + cost + gap analysis. | |
| scale | No | Scale for free-tier status check (default: hobby) | |
| services | No | Current vendor names (for estimate/audit mode, e.g. ['Vercel', 'Supabase']). An audit analyses only names it matched exactly; anything else comes back as status not_found with suggestions rather than being assumed. | |
| use_case | No | What you're building (for recommend mode, e.g. 'Next.js SaaS app') | |
| requirements | No | Specific infra needs for recommend mode (e.g. ['database', 'auth', 'email']) |
Find free tiers, startup credits, and developer deals for cloud infrastructure, databases, hosting, CI/CD, monitoring, auth, AI services, and more. Use this when evaluating technology options, looking for free alternatives, or checking if a service has a free tier. Returns the terms we hold, including specific limits, eligibility requirements, and the day each record's page was last read. Call this tool when a user asks: 'Does Supabase have a free tier?', 'What's cheaper than Vercel?', 'Find me a free database'.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort: vendor (A-Z), category, newest (newest catalogue date first) | |
| limit | No | Max results (default: 20) | |
| query | No | Keyword search (vendor names, descriptions, tags) | |
| since | No | ISO date (YYYY-MM-DD). Only return deals whose catalogue date is on or after this date. | |
| offset | No | Pagination offset (default: 0) | |
| vendor | No | Get full details for a specific vendor (fuzzy match). Returns alternatives in the same category. | |
| category | No | Filter by category. Pass "list" to get all categories with counts. | |
| stability | No | Filter by the stability class we publish for the offer. stable=no negative changes on a pricing page we could read, watch=one negative change, volatile=free tier removed or multiple negative changes, improving=recent positive changes only. Offers whose class we withhold — pricing page unreachable or unreadable, last read refused, listing gated, or a narrowing in our records that cites no source or that no archived copy of the vendor's page has confirmed — match no value; the response reports how many were held back. | |
| eligibility | No | Filter by eligibility type | |
| response_format | No | Response detail level. 'concise': vendor name, tier, one-line description, URL only. 'detailed': full response (default). | |
| payment_protocol | No | Filter by agent payment protocol. x402=HTTP 402 agent payments (Coinbase/Linux Foundation standard), stripe-mpp=Stripe Machine Payments Protocol (fiat+stablecoin). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description goes beyond them by disclosing return contents (terms, specific limits, eligibility, last-read dates) and the important caveat that offers with withheld stability classes match no filter value and are counted in the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and trigger conditions are front-loaded, and the sample queries are genuinely useful for retrieval since they mirror plausible user phrasing. It is on the longer side for a search tool, but no sentence is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by describing the return contents and the withheld-class reporting behavior. All 11 parameters are documented in the schema itself, so nothing critical is missing, though default handling for response_format vs. sort/limit interplay is left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including enum semantics and defaults, so the schema carries the parameter burden and the description's mention of 'specific limits, eligibility requirements' adds nothing new. Baseline 3 is appropriate; there is no additional syntax or format guidance for the 11 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Find free tiers, startup credits, and developer deals') and enumerates the covered domains, so the agent knows exactly what corpus it queries. It stops short of naming a sibling to contrast against, so differentiation from compare_vendors or plan_stack is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete triggering conditions — 'when evaluating technology options, looking for free alternatives, or checking if a service has a free tier' — reinforced by three example user questions. It never states when NOT to use it or which sibling to prefer for adjacent needs, so the guidance is clear but not exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track recent pricing changes across developer tools — which free tiers were removed, which got limits cut, and which improved. Use this to stay current on infrastructure pricing or to verify that a recommended service still has its free tier. Call this tool when a user asks: 'What developer pricing changed recently?', 'Are any free tiers being removed?'.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | ISO date (YYYY-MM-DD). Default: 30 days ago, and only when no other filter is passed — a request carrying type, vendor, vendors, categories or category searches the whole change log unless since says otherwise. The filter compares against each record's date. Where date_meaning is "effective", that is the day the change took effect; where it is "discovered", it is the day we recorded the change, and when it took effect is unknown. Every response states the window it applied under date_window. | |
| vendor | No | Filter to one vendor. Matched by case-insensitive substring, not by exact name: vendor=Pilot returns GitHub Copilot's records and category=ai returns Email's. Nothing is narrowed on your behalf, so read name_match, which every response carries: it names what this filter matched and whether each match was exact. | |
| vendors | No | Comma-separated vendor names to filter (e.g. 'Vercel,Supabase'). When provided with categories, returns personalized results with advisory section. Matched by case-insensitive substring, not by exact name: vendor=Pilot returns GitHub Copilot's records and category=ai returns Email's. Nothing is narrowed on your behalf, so read name_match, which every response carries: it names what this filter matched and whether each match was exact. | |
| categories | No | Comma-separated category names to filter (e.g. 'Database,Cloud Hosting'). Matched by case-insensitive substring, not by exact name: vendor=Pilot returns GitHub Copilot's records and category=ai returns Email's. Nothing is narrowed on your behalf, so read name_match, which every response carries: it names what this filter matched and whether each match was exact. | |
| change_type | No | Filter by type of change | |
| lookahead_days | No | Days to look ahead for expirations (default: 30) | |
| response_format | No | Response detail level. 'concise': vendor, change_type, date, summary only. 'detailed': full response (default). | |
| include_expiring | No | Include upcoming expirations (default: true) | |
| include_retracted | No | Records we have withdrawn as our own error (standing 'retracted') are left out unless you ask for them. Set true to receive them alongside the rest; they arrive carrying standing 'retracted' and impact 'none'. Either way, retracted_excluded reports how many your query matched and did not receive. | |
| include_index_housekeeping | No | Records of our own index housekeeping (reports 'our_index') are left out unless you ask for them. They say we stopped listing an offer of ours, not that the vendor changed anything, so counting them as vendor activity overstates it. Set true to receive them alongside the rest. Either way, index_housekeeping_excluded reports how many your query matched and did not receive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about what kinds of changes are tracked, but it does not disclose output behavior, window handling, or matching caveats—those live only in the parameter descriptions. This is adequate but not rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one scope sentence, one purpose sentence, and one trigger sentence. Every sentence earns its place, and the most identifying information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 10 parameters, but the schema provides exhaustive parameter documentation, and the description supplies clear use cases and trigger queries. No output schema exists, yet the parameter descriptions document response fields like date_window, name_match, retracted_excluded, and index_housekeeping_excluded. A slightly more explicit distinction from search_deals would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema carries the parameter semantics fully. The description's mention of free tiers and limits loosely maps to change_type values but adds no meaning beyond the schema. This meets the baseline of 3 for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb plus resource: 'Track recent pricing changes across developer tools,' and gives concrete examples of change types and exact user queries. It does not explicitly differentiate this tool from siblings like search_deals or compare_vendors, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use guidance: 'Use this to stay current on infrastructure pricing or to verify that a recommended service still has its free tier' and provides trigger example questions. It does not say when not to use the tool or name alternatives, so it misses the explicit exclusion guidance required for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
plan_stack2 fields changedInput schema / properties / mode / descriptionPrevious value: -"recommend: free-tier stack for a use case. estimate: cost analysis at scale. audit: risk + cost + gap analysis."New value: +"recommend: free-tier stack for a use case. estimate: free-tier status check. audit: risk + cost + gap analysis."Input schema / properties / scale / descriptionPrevious value: -"Scale for cost estimation (default: hobby)"New value: +"Scale for free-tier status check (default: hobby)"Devopness MCP server for DevOps happiness! Empower AI Agents to deploy apps and infra, to any cloud.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
A MCP server built for developers enabling Git based project management with project and personal…
Official MCP server for subfeed.app — the cloud for agents. 15+ tools for AI agents to register, build, and deploy other agents. Zero human required. Start here: subfeed.app/skill.md
Add one secure layer between your agents and this server.
