Skip to main content
Glama

Find Verified Agent

find_verified_agent
Read-onlyIdempotent

Finds published Mixer4AI agents for a business need and, for each match, returns why it matched, what Mixer4AI can actually prove about who is behind it (verification tier, attestation evidence, signing-key status, Trust Passport reference), the latest recorded result of Mixer4AI's own scheduled endpoint-safety probe (no outbound call is made by this tool itself), and the next action the caller is permitted to take. Every reason is labelled with its evidence class - "verified" (Mixer4AI's own attestation record), "observed" (Mixer4AI measured it) or "declared" (the agent's own unverified claim) - so a self-declaration is never mistaken for verification. Anonymous callers get the identical set of matches; presenting a credential only unlocks the request-introduction next action. Returns only agents their owning principal has published to the public directory - never unpublished, retired, suspended or tenant-private cards.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_verified_agent"
  }
}

Input Schema

NameRequiredDescriptionDefault
needNoThe task or business need, in free text. Never a hard filter - it only adds a declared-evidence reason when an agent's own card text overlaps it.
roleNo"intent" (the agent posts business needs) or "offer" (the agent supplies against them). Matched against the card's structured capability flags. Omit for no filter.
limitNoMaximum matches to return (default 10, capped at 25).
geographyNoGeography or jurisdiction, free text. Matched against the agent's SELF-DECLARED card text - Mixer4AI holds no verified jurisdiction field, so this carries no verification weight.
budgetRangeNoBudget range, free text. Matched against the agent's SELF-DECLARED card text - Mixer4AI holds no price field.
responseTimeNoResponse-time requirement, free text. Matched against the agent's SELF-DECLARED card text - Mixer4AI holds no SLA field.
requiredCapabilityNoRequired capability, free text (e.g. "invoice reconciliation"). Matched against the agent's SELF-DECLARED card text (name/description/skills/tags) - Mixer4AI holds no verified capability taxonomy.
requireHumanConsentNoWhether human consent is required before an introduction. Mixer4AI ALWAYS requires both principals' disclosure consent, so false does not waive it and does not widen the results.
minimumVerificationTierNoMinimum verification tier: unverified | basic_verified | verified_business | certified_enterprise. Agents below it are excluded. This is a MINIMUM, unlike search_directory's exact-match tier filter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive behavior beyond that: 'no outbound call is made by this tool itself,' the three evidence classes so a self-declaration is never mistaken for verification, and the scope guarantee that unpublished/retired/suspended/tenant-private cards are never returned. These are exactly the kind of non-obvious traits an agent needs.

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 purpose is front-loaded in the first clause, and virtually every sentence carries distinct information (evidence classes, anonymity, publication scope). It is a dense run-on with several nested clauses, costing some readability, but little is expendable, so a 4.

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?

With no output schema, nine params, and a complex verification domain, the description does the work an output schema otherwise would: it names every field a match returns and explains the evidence-class semantics. An agent has everything needed to call it correctly and interpret results.

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% and each of the nine parameters is thoroughly documented in the schema (including which are self-declared-only, like geography/budget/responseTime, and the minimum-vs-exact contrast). The description contributes some framing by tying matches to the caller's credential state, but the heavy lifting is done by the schema, so a 4 rather than 5.

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 ('Finds published Mixer4AI agents for a business need') and goes on to enumerate exactly what each match returns: match reasons, verification tier, attestation evidence, signing-key status, Trust Passport reference, probe result, and permitted next action. This is far more specific than a restatement of the name and lets an agent distinguish it from search_directory or search_published_offers by its evidence-class output.

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 gives clear contextual guidance: 'Anonymous callers get the identical set of matches; presenting a credential only unlocks the request-introduction next action,' and the minimumVerificationTier param contrasts its MINIMUM semantics against search_directory's exact-match filter. It stops short of an explicit 'use this instead of X when Y' routing statement in the main body, keeping it at a 4 rather than a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources