MCP server aggregating developer infrastructure deals, free tiers, and startup programs
Scored across 5 tools
Each tool targets a distinct action—search, compare, track, plan, or referral lookup—so an agent can usually choose correctly. The slight overlap between compare_vendors and search_deals around pricing/free-tier data is the only real ambiguity.
All tools follow a consistent verb_noun pattern in snake_case: compare_vendors, get_referral_code, plan_stack, search_deals, track_changes. Verbs clearly signal the intended operation.
Five tools is well-scoped for a developer-deals assistant. Each tool covers a meaningful part of the workflow without unnecessary duplication.
The set covers discovery, comparison, change tracking, stack planning, and referral lookup—strong coverage for the domain. Missing only peripheral capabilities like direct vendor detail pages or change alerts.
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: cost analysis at scale. audit: risk + cost + gap analysis. | |
| scale | No | Scale for cost estimation (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']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/destructive annotations. It discloses that rankings only demote, never promote; tied offers are ordered by a recomputable seed; free-tier status is based on recorded facts with dates; and audit mode returns not_found for unmatched names rather than assuming them. These are genuinely useful behavioral traits an agent could not infer from the schema alone.
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 dense and every sentence adds useful information; purpose and usage triggers are front-loaded. However, it is a single long paragraph that mixes mode semantics, limitations, ranking mechanics, and example prompts, which makes it harder to scan. Still, there is no filler.
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 tool with 5 parameters, no output schema, and complex mode-dependent behavior, the description covers the key invocation concerns: what each mode returns, how audit handles unmatched names, how ties and rankings behave, what the tool does not model, and when to call it. Nothing critical is left for the agent to guess.
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?
Since schema description coverage is 100%, the baseline is 3, but the description adds meaningful semantics: recommend mode returns a set of offers per role, services must match exactly in audit mode, and use_case/requirements are defined for recommend mode. This exceeds the schema's bare parameter descriptions without fully documenting each enum variant in prose.
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 opens with a specific verb and resource: 'Plan a technology stack with cost-optimized infrastructure choices.' It also clarifies that recommend mode returns a set of tied offers rather than a single pick, and distinguishes the tool from a plain recommender by stating what it does NOT do (model technical fit). This gives the agent a clear, unique purpose.
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 explicit when-to-use conditions: 'starting a new project, evaluating hosting options, or trying to minimize infrastructure costs' and even supplies example user prompts. It also explains mode-specific behavior (recommend vs estimate vs audit) and the exact-match constraint for audit mode, which helps the agent decide if this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, or the listing gated — 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 declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds valuable behavior beyond that: it discloses that results include 'the day each record's page was last read', and the stability parameter documentation (in schema) explains withheld classes. The description could add that results are point-in-time snapshots, but the last-read disclosure already goes beyond the annotation baseline.
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 and front-loads the core purpose before usage context, with only four sentences. It earns its length by including usage triggers and return-value hints, and the example queries at the end are useful rather than padding. Slight redundancy ('Call this tool when...' restates 'Use this when...') keeps it from a 5.
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 an 11-parameter, zero-required, read-only search tool with 100% schema coverage and no output schema, the description covers the main gaps: what the catalogue contains, when to use it, and what the returned record includes. It does not describe pagination behavior or the shape of the 'detailed' response, but the schema's offset/limit descriptions and the response_format enum largely cover that. Overall, the definition is complete enough for reliable invocation.
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 already documents all 11 parameters fully, including enum meanings for stability, response_format, and payment_protocol. The description adds no new per-parameter semantics — it stays at the tool level. Baseline 3 is appropriate when the schema carries the heavy lifting and the description adds no param-level value.
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 leads with a specific verb ('Find') and a precise resource (free tiers, startup credits, developer deals across named categories), and it distinguishes itself from siblings by scoping exactly what the catalogue contains. It even gives three concrete user questions the tool answers, which makes the purpose unmistakable to an agent.
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 call the tool ('when evaluating technology options, looking for free alternatives, or checking if a service has a free tier') and gives literal example queries ('Does Supabase have a free tier?'). It does not enumerate sibling exclusions, but the context is so explicit that an agent can reliably decide to invoke it; this exceeds the 'clear context, no exclusions' bar for a 4.
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, which is the day the change took effect unless date_source is "discovered", in which case it is the day we read the page. 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 declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful context beyond that: it discloses the case-insensitive substring matching behavior with a concrete example (Pilot matches GitHub Copilot), the date_source semantics, the 'nothing narrowed on your behalf' caveat, and the name_match response field. This helps the agent anticipate surprising behavior.
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 front-loaded with purpose and usage triggers before details. Every sentence earns its place — the filtering caveats and response-field notes are genuinely important. It's slightly dense but well-organized, with no wasted words. The structure flows logically from purpose to usage to trigger examples.
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 10 parameters, no output schema, and no required params, the description carries a heavy burden. It covers the key behaviors: substring matching, name_match, retracted records, index housekeeping, and since-window logic. It doesn't explicitly mention response_format or include_expiring defaults, but those are in the schema. The description is complete enough for an agent to call this correctly without surprises.
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%, but the parameter descriptions go far beyond names. The 'vendor' parameter warns about substring matching with a concrete example. The 'since' parameter explains the default-window logic and date_source nuance. The include_retracted and include_index_housekeeping parameters explain exclusion behavior and reporting. This adds substantial meaning beyond the 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?
Description opens with specific verb+resource ('Track recent pricing changes across developer tools') and enumerates exactly what's covered (free tiers removed, limits cut, improvements). Provides concrete user queries ('What developer pricing changed recently?', 'Are any free tiers being removed?') that map directly to the tool, and its scope is clearly distinct from siblings like compare_vendors or search_deals.
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?
Explicit trigger phrases ('Call this tool when a user asks...') tell the agent when to use it, and the stated purpose (staying current on infrastructure pricing, verifying a free tier still exists) gives clear context. It doesn't explicitly name alternatives for when NOT to use it, but the trigger examples are concrete enough to route correctly.
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.
search_deals1 field changedInput schema / properties / sort / descriptionPrevious value: -"Sort: vendor (A-Z), category, newest (recently verified first)"New value: +"Sort: vendor (A-Z), category, newest (newest catalogue date first)"search_deals1 field changedInput schema / properties / since / descriptionPrevious value: -"ISO date (YYYY-MM-DD). Only return deals verified/added after this date."New value: +"ISO date (YYYY-MM-DD). Only return deals whose catalogue date is on or after this date."track_changes3 fields changedInput schema / properties / categories / descriptionPrevious value: -"Comma-separated category names to filter (e.g. 'Database,Cloud Hosting'). Case-insensitive partial match."New value: +"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."Input schema / properties / vendor / descriptionPrevious value: -"Filter to one vendor (case-insensitive)"New value: +"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."Input schema / properties / vendors / descriptionPrevious value: -"Comma-separated vendor names to filter (e.g. 'Vercel,Supabase'). When provided with categories, returns personalized results with advisory section."New value: +"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."track_changes1 field changedInput schema / properties / include_index_housekeepingAdded value: +{
+ "description": "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.",
+ "type": "boolean"
+}track_changes1 field changedInput schema / properties / since / descriptionPrevious value: -"ISO date (YYYY-MM-DD). Default: 7 days ago."New value: +"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, which is the day the change took effect unless date_source is \"discovered\", in which case it is the day we read the page. Every response states the window it applied under date_window."track_changes1 field changedInput schema / properties / include_retractedAdded value: +{
+ "description": "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.",
+ "type": "boolean"
+}search_deals1 field changedInput schema / properties / stability / descriptionPrevious value: -"Filter by free tier stability class. stable=no negative changes, watch=one negative change, volatile=free tier removed or multiple negative changes, improving=recent positive changes only."New value: +"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, or the listing gated — match no value; the response reports how many were held back."check_balanceget_referral_code1 field changedInput schema / properties / api_keyRemoved value: -{
- "description": "Your API key from register_agent, for attribution tracking. Optional — unauthenticated calls still return the code.",
- "type": "string"
-}leaderboardmanage_friendsmy_referral_codesregister_agentrequest_payoutsubmit_referral_codeDevopness 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.
