agentery

price_benchmark

Fair-price benchmarks for a capability described in natural language. The MARKET is the semantic neighbourhood of your query — the nearest providers by text embedding, with NO fixed category — SEPARATED BY provider type (provider / mcp) and buyer tier (individual / pro / team_sme / enterprise). Each cohort reports median, mean, stdev, p25/p75, min–max range and n; a single blended provider+MCP median is NEVER the default. Supply provider_type and buyer_tier whenever the user makes them known (e.g. 'an individual MCP', 'a professional provider', 'enterprise'); when neither is known the tool returns the populated per-type/per-tier cohort matrix. Prices come from the canonical pricing engine run over the priced members of the neighbourhood, so the figures match the rest of the site to the digit. Pass query (the natural-language capability); task is accepted as an alias for the query text. When nothing priced is semantically close it returns resolved:false with a note, never a fabricated figure.

Input Schema

TableJSON Schema

Name	Required	Description
`niche`	No	Legacy alias of `query`, kept for older clients — prefer `query`.
`sector`	No	Sector name, e.g. 'legal' (ignored if a query is given)
`buyer_tier`	No	Buyer tier being priced. Set when the user describes who is buying (an individual, a professional, a team/SME, or an enterprise). An individual licence must never be represented by the SME or enterprise price.
`pricing_unit`	No	Optional pricing unit to hold constant (e.g. 'flat', 'per_seat', 'per_agent'). Incompatible units are never combined.
`provider_type`	No	Delivery type being priced. Set when the user says provider, MCP or API. Omit (or 'all') to get the per-type matrix instead of a blended figure. 'api' is recognised but not yet a separate commercial cohort (folded into provider).
`response_mode`	No	'summary' (default): compact per-type/per-tier benchmark matrix. 'full': also returns the deprecated blended legacy block + AEPI index.

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 of behavioral disclosure. It explicitly reveals that the market is a semantic embedding neighbourhood, that the blended median is never default, that prices come from a canonical pricing engine, and that the tool returns resolved:false rather than fabricating a figure. It also flags the deprecated blended legacy block in full mode.

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?

The description is front-loaded with purpose and organised by market definition, output stats, parameter guidance, and failure behavior. It is longer than strictly necessary, but every sentence adds substantive behavioral or usage detail, so it earns a high score despite some verbosity.

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?

For a 6-parameter tool with no output schema and no annotations, the description is unusually complete: it covers the matching algorithm, cohort statistics, input conditions, pricing-engine fidelity, and failure semantics. It falls short of 5 only because of the query/niche parameter inconsistency and the lack of an explicit response structure description.

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 description coverage is 100%, giving a baseline of 3, but the description adds meaningful semantics: the query/task alias relationship, when to supply buyer_tier/provider_type, incompatible pricing units not being combined, and response_mode full-mode behavior. However, the instruction to 'Pass `query`' conflicts with the input schema where `niche` is the listed legacy alias and `query` is not actually a defined property, which weakens the guidance slightly.

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 specific verb-resource statement: 'Fair-price benchmarks for a capability described in natural language.' It then distinguishes itself from siblings by emphasizing semantic neighbourhood, no fixed category, and per-provider-type/per-buyer-tier cohort separation, clearly differentiating from tools like get_price_index and compare_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 provides clear usage context: supply provider_type and buyer_tier when known, omit them to get the per-type/per-tier matrix, pass the natural-language query, and expect resolved:false when nothing priced is close. It does not explicitly state when-not-to-use or name alternative tools, though the context is otherwise strong.

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?