Skip to main content
Glama

agentery

by com.agentery
OverviewDiscussionsAdmin

compare_providers

Step 3 of the buyer path. Side-by-side capability + plan-level prices for 2–6 providers (e.g. the Pro tier). Inputs are resolved to REAL providers — exact handle, then exact display name — and are NEVER silently swapped for a fuzzy match: unknown inputs come back in unresolved_inputs with suggested_matches and a ready-to-retry corrected_call, and if EXACTLY ONE input is real (the other was invented/mistyped) it does NOT dead-end — it returns comparison_status: compared_with_market_peers, comparing the real provider against its actual in-market competitors — its nearest providers by text-embedding — (listed in compared_against_peers, with a recovery_note); only when ZERO inputs resolve does it return comparison_status: insufficient_valid_providers. When the compared providers are different delivery types it sets mixed_provider_types + a comparability_warning (a hosted agent and an MCP server are not directly equivalent). Full evidence-scored cards for 2-6 handles side by side, each with observed price, all-time community upvotes and provider type. Each card carries the full how_to_connect object (website, docs, MCP endpoint + config_snippet, A2A card, API) so you can act on the winner directly. Each card also carries reported_success — the machine-reported outcome rate from report_outcome (null until 5+ distinct correlated reporters in 90 days). Report your own outcome after using the winner. Accepts provider_ids (aliases: handles, ids; a comma-separated string is also accepted). Use after search_providers or research_capability; when a compared provider is over budget or weakly matched, inline suggested_alternatives are returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskNoOptional. The buyer's job in plain words; used as the service_view heading.
serviceNoOptional. A service recipe whose fixed requirements and evidence fields are applied (see service_view.requirements).
optionalNoOptional preferences: reported in service_view but never gating.
provider_idsYes2-6 provider handles from search_providers/market_gaps, e.g. ["openhands","lexaclaw"]
requirementsNoOptional. Mandatory requirements as plain phrases (e.g. "sanctions screening", "documented MCP interface"). Adds an ADDITIVE service_view: per-provider evidence matrix from stored first-party page text — supported / not_supported / unknown with the excerpt and observation date; unknown never means unsupported.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / optional
      Added value: +{
+  "description": "Optional preferences: reported in service_view but never gating.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / requirements
      Added value: +{
+  "description": "Optional. Mandatory requirements as plain phrases (e.g. \"sanctions screening\", \"documented MCP interface\"). Adds an ADDITIVE service_view: per-provider evidence matrix from stored first-party page text — supported / not_supported / unknown with the excerpt and observation date; unknown never means unsupported.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / service
      Added value: +{
+  "description": "Optional. A service recipe whose fixed requirements and evidence fields are applied (see service_view.requirements).",
+  "enum": [
+    "supplier-verification",
+    "contract-review",
+    "developer-capabilities",
+    "cheaper-alternatives"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / task
      Added value: +{
+  "description": "Optional. The buyer's job in plain words; used as the service_view heading.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / provider_ids / description
      Previous value: -"2-6 agent handles from search_agents/market_gaps, e.g. [\"openhands\",\"lexaclaw\"]"New value: +"2-6 provider handles from search_providers/market_gaps, e.g. [\"openhands\",\"lexaclaw\"]"
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: exact-match resolution policy, no silent fuzzy swapping, three-way status outcomes for unresolved inputs, mixed-provider-type warnings, peer fallback behavior, and machine-reported success caveats. It even explains corrected_call and recovery_note fields.

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

Conciseness3/5

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

The content is front-loaded with purpose and packed with valuable edge-case detail, but it is a single dense run-on paragraph with heavy parentheticals; restructuring into bullets would improve scannability. It is more exhaustive than concise.

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?

Despite no output schema, the description enumerates nearly every important output field and state: comparison_status values, unresolved_inputs, suggested_matches, corrected_call, compared_against_peers, recovery_note, mixed_provider_types, comparability_warning, reported_success, and how_to_connect. It also covers the count constraints and post-use reporting, so an agent can invoke and interpret results without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful input semantics: provider_ids aliases ('handles, ids'), comma-separated string acceptance, and the 2–6 handle constraint tied to search_providers/market_gaps. It does not re-describe all params, but that is already covered in schema.

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?

Opens by identifying itself as 'Step 3 of the buyer path' and states the core action: 'Side-by-side capability + plan-level prices for 2–6 providers.' It then describes 'Full evidence-scored cards for 2-6 handles side by side,' making the deliverable unambiguous and distinct from siblings like search_providers or market_gaps.

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?

The description explicitly positions the tool in a sequence ('Step 3', 'Use after search_providers or research_capability') and mentions inline 'suggested_alternatives' for over-budget or weakly matched providers. It does not explicitly list when-not-to-use scenarios or contrast with rank_providers_for_workflow, so it falls just short of a 5.

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

All agentery toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources