agentery

compare_providers

Call this to decide between shortlisted providers. 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

Name	Required	Description	Default
`provider_ids`	Yes	2-6 provider handles from search_providers/market_gaps, e.g. ["openhands","lexaclaw"]

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses behavior: exact-match resolution ('NEVER silently swapped for a fuzzy match'), edge cases for one or zero valid inputs, mixed_provider_types warnings, and the meaning of reported_success (null until 5+ distinct correlated reporters in 90 days). This is exceptionally transparent.

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

Conciseness2/5

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

The description is a single dense paragraph with many clauses, semicolons, and parentheticals, making it hard to scan. Key output details are buried mid-paragraph. While every sentence carries technical importance, the lack of bullet points or front-loading hurts cognitive parsing for an agent.

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?

Given there is no output schema, the description thoroughly covers return structure: cards with observed price, community upvotes, provider type, how_to_connect object, reported_success, and specific comparison_status values. It also addresses edge cases and follow-up actions (report outcome), making it highly complete for invocation.

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?

The input schema covers provider_ids at 100%, but the description adds critical details: accepted aliases ('handles, ids') and that a comma-separated string is also accepted. This goes beyond the schema's array type and improves invocation flexibility.

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 opens with a clear directive: 'Call this to decide between shortlisted providers.' It further specifies the output as 'Full evidence-scored cards for 2-6 handles side by side,' distinguishing it from single-provider tools like get_provider and from search/research tools like search_providers.

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 states it should be used after search_providers or research_capability, and notes when inline suggested_alternatives will appear. It does not explicitly exclude scenarios like querying a single provider, but the workflow context is clear enough.

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

All agentery 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.2/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, but a few pairs could cause confusion: get_provider vs get_provider_profile overlap in scope (one is a card, the other a full profile), and research_capability explicitly bundles find_niche, niche_report, price_benchmark, and search_providers, creating layered redundancy. However, the detailed descriptions clearly differentiate the entry-point tools from the lower-level ones.

Naming Consistency4/5

The majority follow a verb_noun pattern (create_, delete_, get_, search_, suggest_, etc.), but a few tools use bare noun phrases (demand_signals, market_gaps, niche_report, price_benchmark) rather than imperative or get_ prefixes. This is a minor inconsistency that doesn't harm readability.

Tool Count4/5

At 19 tools, the set is slightly above the ideal 3-15 range but each tool serves a distinct, justified function within the market-intelligence and provider-directory domain. The count feels appropriate for the breadth of features (search, research, comparison, pricing, indexes, benchmarks, and feedback).

Completeness5/5

The tool surface is very comprehensive: full CRUD for custom benchmarks, multiple discovery paths (search, research, gaps, demand signals), pricing and index tools, profile/detail tools, comparison and alternatives, plus outcome reporting. There are no obvious dead ends or missing critical operations for the stated purpose.

Resources

Need Help?