Skip to main content
Glama

AgentDeals

by io.github.robhunter
OverviewDiscussionsAdmin

plan_stack

Read-only

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'.

Input Schema

NameRequiredDescriptionDefault
modeYesrecommend: free-tier stack for a use case. estimate: free-tier status check. audit: risk + cost + gap analysis.
scaleNoScale for free-tier status check (default: hobby)
servicesNoCurrent 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_caseNoWhat you're building (for recommend mode, e.g. 'Next.js SaaS app')
requirementsNoSpecific infra needs for recommend mode (e.g. ['database', 'auth', 'email'])

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / mode / description
      Previous 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."
    • changedInput schema / properties / scale / description
      Previous value: -"Scale for cost estimation (default: hobby)"New value: +"Scale for free-tier status check (default: hobby)"
  2. Changed1 schema field changed
    • changedInput schema / properties / services / description
      Previous value: -"Current vendor names (for estimate/audit mode, e.g. ['Vercel', 'Supabase'])"New value: +"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."
  3. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  4. Added

TDQS

A4.1/5.0
Behavior5/5

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

With readOnlyHint already covering safety, the description adds genuinely non-obvious behavior: no technical-fit modeling ('a vector store and a relational database sit in the same category'), rankings only demote, ties ordered by a recomputable published seed at /criteria, and free-tier data annotated with recorded facts and dates. This is exactly the context annotations cannot supply.

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

Conciseness4/5

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

Purpose is front-loaded in sentence one, and the caveats about non-picks, missing technical fit, and demote-only rankings each carry real decision value. It is on the long side and the /criteria pointer and quoted user questions could be tightened without losing meaning.

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?

No output schema exists, so the description's explanation of the per-role offer sets is what makes the return legible. However, it only describes recommend-mode output; what estimate and audit return is left to the enum hint 'risk + cost + gap analysis,' which is a residual gap for a 3-mode 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?

Schema coverage is 100%, so mode/scale/services/use_case/requirements are already documented, and the description mainly elaborates recommend-mode behavior rather than adding per-parameter semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

Opens with a specific verb+resource: 'Plan a technology stack with cost-optimized infrastructure choices,' and then pins down what the return actually looks like (a set of tied offers per role, not a single pick). It never names a sibling (compare_vendors, search_deals) or states how it differs from them, so it lands at 4 rather than 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?

Gives concrete trigger conditions ('starting a new project, evaluating hosting options, or trying to minimize infrastructure costs') plus literal user phrasings that should route here. It sets an expectation for recommend mode but offers no exclusions or alternative-tool routing, which keeps it below 5.

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

All AgentDeals toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources