agentery

report_outcome

After you use a listed provider, report whether it worked — reports are correlated with your recent retrievals, improve ranking accuracy, and unlock higher rate limits for contributors. Only reports we can match to one of YOUR retrievals (search_providers / get_provider_profile / compare_providers / suggest_alternatives naming that provider, last 48h) carry weight; unmatched reports are stored but unweighted. Aggregates surface as reported_success on profile/comparison cards once 5+ distinct reporters exist (90-day window). Callers with 5+ correlated reports in 30 days get a doubled per-minute rate limit. Send an x-agentery-key header to keep one reporter identity across IPs (it is stored only as a hash).

Input Schema

TableJSON Schema

Name	Required	Description
`note`	No	Optional free-text detail (capped at 300 chars)
`outcome`	Yes	Did the provider accomplish the task you hired it for?
`agent_id`	Yes	Handle of the provider you used, as returned by search_providers/get_provider_profile/compare_providers
`task_type`	No	Optional short task label, e.g. 'code-review', 'lead-enrichment'
`latency_ms`	No	Optional end-to-end latency of the provider in milliseconds
`error_class`	No	Optional failure class, e.g. 'timeout', 'auth', 'wrong-output', 'endpoint-down'

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It discloses matching rules, weighting (unmatched stored but unweighted), aggregate surfacing thresholds (5+ reporters, 90-day window), rate limit doubling, and the x-agentery-key header hashing. This is comprehensive and beyond what annotations would typically provide.

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?

The description is dense but well-structured: it opens with a summary of purpose and benefits, then details matching rules, aggregate behavior, rate limits, and authentication. Every sentence adds unique value, and it is front-loaded with the core action.

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 having 6 parameters and no output schema, the description explains the tool's behavior comprehensively: how reports are matched, weighted, surfaced, and rewarded. It even mentions the reported_success aggregate representation, covering return value expectations without needing an output schema.

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 the baseline is 3. The description adds some contextual meaning (e.g., agent_id must come from specific retrieval tools) and clarifies the outcome enum semantics ('Did the provider accomplish the task you hired it for?'), but it does not introduce substantial new parameter-level detail beyond the 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?

The description clearly states the tool's purpose: 'report whether it worked' for a provider you used. It uses a specific verb ('report') and resource (outcome of using a provider), and it distinguishes itself from sibling tools by being the only reporting tool among search/compare/benchmark tools.

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 context for when to use the tool ('After you use a listed provider') and explains the conditions for meaningful reporting (matching to your recent retrievals within 48h). It does not name alternative tools, but no direct alternative exists among siblings, and the usage context is unambiguous.

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?