agentery

find_market

Map a natural-language task, capability or service to its live MARKET — the semantic neighbourhood of the closest-matching providers, found by text-embedding nearness (NO fixed category). For buyers ('a provider that monitors competitor pricing'), sellers ('what should I charge for lead-generation automation') or sizing a space. Pricing-intent boilerplate is stripped before matching. Returns the market label, how many providers are in the neighbourhood and how many are priced, nearest (the closest providers with observed price and relevance/cosine), and pricing_by_tier — median, mean, stdev, p25/p75, min–max range and n per buyer tier (individual/pro/team_sme/enterprise), computed by the canonical pricing engine over the priced neighbourhood. match_certainty is 'confident' when real neighbours exist and 'uncertain' when nothing is close (pricing WITHHELD). Accepts task (aliases: query, q). For the full market read + shortlist in ONE call, use research_capability instead. Read-only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`task`	No	A natural-language task, capability or service, e.g. 'reconcile supplier invoices'
`query`	No	Alias for task (back-compat) — a natural-language task, capability or service

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: it uses text-embedding nearness, has no fixed category, strips pricing-intent boilerplate, and withholds pricing when match_certainty is 'uncertain'. It also details what the output includes (market label, provider counts, pricing_by_tier stats) and that it is read-only. This is comprehensive behavioral transparency.

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 dense with information but well-structured, front-loading the purpose and then detailing outputs. Every sentence carries value, though it is longer than necessary; a few clauses could be tightened without losing meaning. Still, it is efficient for the tool's complexity.

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?

There is no output schema, so the description fully explains return values, including the pricing_by_tier statistics and match_certainty behavior. It covers parameters, use cases, and output semantics comprehensively, leaving no critical gaps for an agent to infer. The tool's complexity is well matched by the description's completeness.

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%, so baseline is 3. The description adds a concrete example ('reconcile supplier invoices') and mentions the alias, but does not add significant meaning beyond the schema's existing descriptions. It is adequate but not additive beyond what the schema already provides.

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 the tool maps a natural-language task to its closest-matching market neighborhood, with explicit mention of buyers, sellers, and sizing. It distinguishes itself from sibling tools like research_capability by noting when to use that alternative. The verb 'map' and specific output details make the purpose unmistakable.

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?

The description provides explicit when-to-use guidance for buyers, sellers, and sizing, and explicitly names research_capability as the alternative for a one-call full market read + shortlist. It also clarifies that pricing-intent boilerplate is stripped before matching, adding context. This is a clear usage directive with alternatives.

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?