BuyAPI

stacks.recommend

Read-onlyIdempotent

Recommends a complete stack from BuyAPI's corpus with a structured decision matrix, cost estimate, assumptions, unknowns, alternatives, and sources.

Use this when the user is starting a project or asks for a complete multi-layer stack choice. Do not use this for local coding/debugging/docs questions that do not involve software or vendor selection. Do not call vendors.resolve first; this tool handles retrieval and ranking.

Input Schema

TableJSON Schema

Name	Required	Description
`workload`	No	Explicit workload assumptions for directional cost estimates. Missing fields become assumptions, not fabricated precision.
`stackFacts`	No	Optional derived stack facts such as languages, frameworks, runtimes, package managers, test tools, and dev workflow. Do not pass source code or secrets.
`constraints`	No	Budget, scale, existing tools, team size, compliance needs
`stackContext`	No	Optional existing stack context from a repo scan or saved private stack. Agents should pass derived tool metadata only, not source code.
`projectDescription`	Yes	What the user is building

Output Schema

TableJSON Schema

Name	Required	Description	Default
`stack`	No
`claims`	No
`sources`	No
`coverage`	No
`unknowns`	No
`costEstimate`	No
`decisionMatrix`	No
`alternativesConsidered`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed3 schema fields changedMay 7, 2026

changedInput schema / properties / workload / description

Previous value: -"Explicit workload assumptions for deterministic cost estimates. Missing fields become assumptions, not fabricated precision."New value: +"Explicit workload assumptions for directional cost estimates. Missing fields become assumptions, not fabricated precision."

addedOutput schema / properties / claims

Added value: +{
+  "items": {},
+  "type": "array"
+}

addedOutput schema / properties / coverage

Added value: +{
+  "additionalProperties": {},
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

Changed1 schema field changedMay 4, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "alternativesConsidered": {
+      "items": {},
+      "type": "array"
+    },
+    "costEstimate": {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "decisionMatrix": {
+      "items": {},
+      "type": "array"
+    },
+    "sources": {
+      "items": {},
+      "type": "array"
+    },
+    "stack": {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "unknowns": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedMay 1, 2026

addedInput schema / properties / stackFacts

Added value: +{
+  "description": "Optional derived stack facts such as languages, frameworks, runtimes, package managers, test tools, and dev workflow. Do not pass source code or secrets.",
+  "properties": {
+    "devWorkflow": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "frameworks": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "languages": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "packageManagers": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "runtimes": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "testing": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedMay 1, 2026

addedInput schema / properties / stackContext

Added value: +{
+  "description": "Optional existing stack context from a repo scan or saved private stack. Agents should pass derived tool metadata only, not source code.",
+  "items": {
+    "properties": {
+      "category": {
+        "description": "The role/category this tool fills",
+        "type": "string"
+      },
+      "confidence": {
+        "description": "Scanner or user confidence for this detected tool",
+        "type": "string"
+      },
+      "vendorSlug": {
+        "description": "BuyAPI vendor ID, e.g. /database/convex",
+        "type": "string"
+      }
+    },
+    "required": [
+      "vendorSlug",
+      "category"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

First observedApr 29, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare read-only, open-world, and idempotent behavior, so the bar is lower. The description adds that the tool performs both retrieval and ranking internally, and that it will output assumptions and unknowns, giving a sense of how complete the answer will be and where uncertainty lies. This is meaningful context beyond the annotations, though it does not describe every internal heuristic.

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?

Three sentences, each with a distinct purpose: (1) what the tool does and its output, (2) when to use or avoid it, (3) a specific process note about vendors.resolve. No filler or repeated schema content.

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

Completeness5/5

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

For a tool with 5 parameters and nested objects, the description is thorough: it explains the core function, delivery format, usage boundaries, and internal process. With an output schema present, it appropriately avoids detailing the return structure. The mention of 'from BuyAPI's corpus' and the assumption/unknowns behavior provides important context for decision-making.

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 input schema has 100% coverage with substantive descriptions for all parameters (e.g., workload: 'Explicit workload assumptions...', constraints: 'Budget, scale, existing tools...'), so the description does not need to reiterate them. It reinforces that missing workload fields become assumptions, but this is already in the schema. The description adds minimal extra parameter-specific meaning.

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

Purpose5/5

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

The description uses the specific verb 'Recommends' and clearly identifies the resource ('complete stack') plus the key output components (decision matrix, cost estimate, assumptions, unknowns, alternatives, sources). It distinguishes from siblings by stating that this tool handles retrieval and ranking internally, so it is not a generic find/compare tool.

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

Usage Guidelines5/5

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

Explicit guidance is given: 'Use this when the user is starting a project or asks for a complete multi-layer stack choice.' It also states what NOT to use it for ('local coding/debugging/docs questions') and instructs to avoid calling vendors.resolve first, clearly delimiting its scope and alternatives.

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

All BuyAPI tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Every tool targets a distinct purpose: stack examples vs. recommendation, vendor discovery vs. comparison vs. details vs. cost estimation vs. evidence. There is no functional overlap, and the descriptions clearly delineate boundaries.

Naming Consistency4/5

Tools follow a domain.action pattern (stacks.*, vendors.*), which is predictable. However, action names mix camelCase (findSimilar, estimateCost) with lowercase (recommend, compare), a minor inconsistency that doesn't hinder understanding.

Tool Count5/5

Seven tools cover the vendor and stack selection domain without being overwhelming or sparse. Each tool earns its place by addressing a distinct step in the workflow.

Completeness5/5

The tool set covers the complete workflow: initial vendor discovery (resolve), comparison (compare), detailed info (details), cost estimation (estimateCost), evidence retrieval (evidence), and stack examples/recommendations (findSimilar, recommend). No obvious gaps.

stacks.recommend

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources