Trust infrastructure for AI agents: check reliability, verification, and trustDecision by URL.
Scored across 5 tools
Most tools serve distinct lookup/monitoring functions, but check_agent_trust and list_agents with endpointUrl substantially overlap, both checking trust status for an exact invocation URL. The descriptions mitigate this somewhat by presenting check_agent_trust as preferred, but an agent could still easily choose the wrong one.
All tool names follow a clear snake_case verb_noun pattern: check_, get_, get_, list_, and send_. The verbs accurately reflect the action and the object nouns align consistently with the resources being accessed.
Five tools cover lookup, trust checking, health monitoring, discovery, and heartbeat reporting without excessive fragmentation. This is a well-scoped set for an agent trust registry.
The core trust-lookup, profile access, health monitoring, and heartbeat submission workflows are covered. There is no explicit registration/update path for owned agents or endpoint-ownership verification initiation, but the primary 'check before invoking' workflow is complete.
The preferred check before invoking an unknown external agent. Read-only, requires no AgentTrust API key or account. Looks up an agent by its exact invocation URL among AgentTrust's already-observed public agents and returns its status, endpoint-ownership verification, reliability score, and a machine-readable trustDecision (recommended, confidence, reasons). Does NOT contact endpointUrl itself during this check — it only reads AgentTrust's own existing monitoring history. An unregistered URL returns { matched: false }, never an error.
| Name | Required | Description | Default |
|---|---|---|---|
| endpointUrl | Yes |
| Name | Required | Description |
|---|---|---|
| name | No | |
| slug | No | |
| status | No | |
| matched | Yes | |
| verified | No | |
| trustDecision | No | |
| reliabilityScore | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers: it is read-only, requires no credentials, does NOT contact the endpoint (only reads existing monitoring history), specifies the returned fields (status, verification, reliability score, trustDecision), and handles unregistered URLs gracefully (returns { matched: false }, never an error). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key purpose, then methodically covers what it does, what it does not do, and edge-case behavior. Every sentence earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no annotations, and an output schema (even though not shown), the description is fully sufficient. It covers purpose, usage, behavior, return values, and the unregistered-URL case, leaving no critical ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by clarifying that endpointUrl must be the 'exact invocation URL' and is used to look up the agent among observed public agents. However, it does not provide format examples or clarify edge cases (e.g., trailing slashes, scheme required), and it is the only parameter. This is adequate but not rich enough for a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('check'), a specific resource (agent trust via invocation URL), and the exact purpose: look up an agent's trustworthiness before invocation. It clearly distinguishes itself from siblings by being 'the preferred check before invoking an unknown external agent' and explicitly notes it does not contact the endpoint, unlike other tools that might perform health checks or retrieve agent details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use it ('before invoking an unknown external agent') and provides a key condition ('requires no AgentTrust API key or account'). While it calls itself the 'preferred' check, it does not explicitly name alternative sibling tools or conditions when they would be more appropriate, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one AgentTrust agent's public profile by slug, including its structured Agent Card, current reliability score, and a machine-readable trustDecision (recommended, confidence, reasons) for deciding whether to invoke it.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The agent's URL slug (from its public profile or a list_agents result). |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| slug | Yes | |
| status | Yes | |
| version | Yes | |
| verified | Yes | |
| agentCard | Yes | |
| createdAt | Yes | |
| latencyMs | Yes | |
| httpStatus | Yes | |
| description | Yes | |
| capabilities | Yes | |
| lastCheckedAt | Yes | |
| trustDecision | Yes | |
| reliabilityScore | Yes | |
| ownershipVerifiedAt | Yes | |
| reliabilityScoreComputedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly signals a read-only, public-profile retrieval, names the returned components, and states the decision-making purpose. It does not discuss edge-case behavior, but 'get' plus 'public profile' sufficiently indicates a side-effect-free operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the core action and resource, then lists the relevant result components. Every clause earns its place and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a simple, one-parameter tool with an output schema present. It explains what the response contains, and the output schema can cover exact return fields. It could be slightly stronger by noting when to prefer get_agent_health, but that is a secondary concern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter already has a clear description in the schema. The tool description adds only 'by slug', which aligns with the schema but does not materially expand parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, 'get', and a specific resource, 'one AgentTrust agent's public profile by slug', and enumerates what is included (Agent Card, reliability score, trustDecision). This clearly distinguishes it from get_agent_health, list_agents, and send_heartbeat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need a specific agent's profile and a trustDecision to decide whether to invoke it. However, it does not explicitly state exclusions or name alternatives like get_agent_health for health-specific checks or list_agents for discovering slugs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one agent's current effective health status and monitoring detail — derived from heartbeat freshness for push-mode agents, or the latest pull check otherwise.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The agent's URL slug (from its public profile or a list_agents result). |
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| status | Yes | |
| agentId | Yes | |
| latencyMs | Yes | |
| httpStatus | Yes | |
| checkStatus | Yes | |
| lastCheckedAt | Yes | |
| reliabilityScore | Yes | |
| reliabilityScoreComputedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal the derivation logic (heartbeat freshness vs latest pull check), which is meaningful. However, it does not explicitly state that the operation is read-only or discuss auth, rate limits, or failure behavior, leaving some safety context implicit in the word 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tightly worded sentence that front-loads the object being fetched and then adds the key derivation distinction in a dependent clause. There is no filler, repetition of the schema, or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, the description covers the essential scoping and derivation behavior. The main gap is that it does not explicitly route the agent away from get_agent for general agent info, though the 'health' scope and sibling names make that inference straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 single slug parameter is already well documented in the schema as a URL slug from a public profile or list_agents result. The description itself adds no further parameter-level semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: get one agent's current effective health status and monitoring detail. It also clarifies the derivation basis (heartbeat freshness vs pull check), which distinguishes it from the sibling get_agent (general agent info) and send_heartbeat (a write action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool is relevant: health monitoring for push-mode agents versus pull-mode agents. It does not explicitly name alternatives or state when not to use it, so exclusion guidance is left to inference, but the health-focused wording makes the intended use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover AgentTrust agents. Pass endpointUrl to check the trust status of a specific external agent by its exact invocation URL before deciding whether to invoke it — the response includes a reliability score, endpoint-ownership verification status, and a machine-readable trustDecision (recommended, confidence, reasons). Without endpointUrl, returns the plain paginated listing of public agents, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max agents to return (1-100, default 20). | |
| cursor | No | Opaque pagination cursor from a previous call's nextCursor. | |
| endpointUrl | No | Look up the agent registered with exactly this invocation URL, instead of browsing the full listing — the entry point for a trust check on an agent you only have a URL for. Matches ignore trailing-slash and scheme/host-casing differences only — never a fuzzy match. Returns an empty list, not an error, if nothing is registered with that URL. Unlike a plain (unfiltered) call, results here also include reliabilityScore, lastCheckedAt/latencyMs/httpStatus, and a derived trustDecision ({recommended, confidence, reasons}) so a caller can decide whether to interact with the agent from this one call. |
| Name | Required | Description |
|---|---|---|
| agents | Yes | |
| pagination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses key behaviors: matching rules (ignores trailing-slash and casing, never fuzzy), error handling (returns empty list, not error), and the additional fields returned in trust-check mode (reliabilityScore, ownership verification, trustDecision). This is thorough and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences but dense with information. It front-loads the primary purpose and then details both modes without redundancy. It's slightly long but justified by the complexity of the dual-mode behavior. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values need not be explained in detail. The description covers both usage modes, edge cases (empty list for unmatched URL), matching rules, and the trust-decision fields. It is complete for an agent to select and invoke correctly without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value for endpointUrl: explains its purpose, matching semantics, empty-list behavior, and extra fields returned. For limit and cursor, the schema already documents them, but the description doesn't add much—however, that's acceptable given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core function: 'Discover AgentTrust agents' and distinguishes two modes: a plain listing and a trust check via endpointUrl. It names the resource (agents) and the specific verb (discover/list/check), making it distinct from siblings like get_agent_health or send_heartbeat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to pass endpointUrl ('to check the trust status of a specific external agent... before deciding whether to invoke it') and when not to ('Without endpointUrl, returns the plain paginated listing'). This gives clear usage context, though it doesn't explicitly contrast with sibling tools like get_agent_health, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a push-style heartbeat for an agent you own, marking it alive right now. The server sets the timestamp; no client-supplied time is accepted.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The agent's URL slug (from its public profile or a list_agents result). |
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| status | Yes | |
| lastHeartbeatAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a mutation ('Record') and adds a key behavioral trait: 'The server sets the timestamp; no client-supplied time is accepted.' It also states an ownership requirement. This provides meaningful context beyond the schema, though it could mention error cases or idempotency, which are not essential for a simple heartbeat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste, front-loading the core purpose and then adding the timestamp constraint. Every word contributes, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter action with an output schema (so return values are documented elsewhere), the description covers the essential behavior: what it does, ownership, and server-side timestamping. It could mention prerequisites like authentication or error handling, but those are likely implied by the platform. Overall, it is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'slug' with a clear description ('The agent's URL slug from its public profile or a list_agents result'). Schema description coverage is 100%, so the description adds no additional parameter-specific information. The baseline of 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Record' and the resource 'a push-style heartbeat for an agent you own', specifying the action and scope. It distinguishes itself from the read-only siblings (get_agent, get_agent_health, list_agents) by indicating a write operation, so an agent can tell it apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying 'for an agent you own', which gives a prerequisite condition. However, it does not explicitly mention when not to use this tool or name alternatives like get_agent_health for checking status. The context is clear but lacks explicit exclusions or routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_agent_trustget_agentget_agent_healthlist_agentssend_heartbeatTrust infrastructure for AI agents: read a verifiable Trust Rating, claim an identity, earn a badge.
Trust infrastructure for AI agents. Portable reputation (JTS 0-5), agent discovery, vouching.
Trust verification for AI agents: identities, domains, phishing, contacts, Trust Circle, Vault.
Evidence-first trust verdicts for AI-agent services — query one before you transact.
Add one secure layer between your agents and this server.
