Skip to main content
Glama

BuyAPI

by io.github.TheSnakeFang

vendors.compare

Read-onlyIdempotent

Compares two or more already-known BuyAPI vendors for a specific workload or decision.

Use this when the candidate set is known, for head-to-head questions like "Convex vs Supabase vs Neon for a realtime SaaS" or "Stripe vs Paddle for a marketplace". If the user has not named candidates, use vendors.resolve first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe user's decision context
workloadNoExplicit workload assumptions for directional cost estimates. Missing fields become assumptions, not fabricated precision.
vendorIdsYesBuyAPI vendor IDs, e.g. ['/database/convex', '/database/neon']

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo
queryNo
claimsNo
messageNo
coverageNo
decisionMatrixNo
suggestedNextStepsNo
availableCategoriesNo

Schema Changelog

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

  1. Changed3 schema fields changed
    • 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"
+}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "availableCategories": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "decisionMatrix": {
+      "items": {},
+      "type": "array"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "query": {
+      "type": "string"
+    },
+    "suggestedNextSteps": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  3. First observed

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the 'already-known' precondition but that is more usage guidance than behavioral detail. No new side effects, limitations, or rate limits are disclosed beyond the schema's note about workload assumptions (which lives in the schema description, not here).

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?

Two sentences that are front-loaded with the core function, then provide concrete examples and the alternative tool. Every word earns its place; no filler or redundancy.

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?

The description, combined with complete schema descriptions and a rich output schema, provides sufficient context for correct invocation. It covers the preconditions (already-known IDs), the decision context, and the fallback to vendors.resolve when the candidate set is unknown. The output schema handles return-value expectations.

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 description coverage is 100% (query, vendorIds, workload all have descriptions). The tool description adds no new meaning beyond echoing the idea of a 'specific workload or decision,' which aligns with the query/parameters but does not enrich them further.

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 clearly states 'Compares two or more already-known BuyAPI vendors' with a specific verb and resource. It also distinguishes itself from siblings by specifying 'already-known' and referencing vendors.resolve for unnamed candidates.

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?

Explicitly provides when-to-use: 'Use this when the candidate set is known, for head-to-head questions...' and when-not-to-use: 'If the user has not named candidates, use vendors.resolve first.' Names the alternative tool.

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

All BuyAPI toolsInspect
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.

Resources