Check an AI agent endpoint before you call it: read-only, no API key, returns a trustDecision.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 5 tools
check_agent_trust and list_agents with endpointUrl both perform a pre-invocation trust check by exact URL, and check_agent_trust, get_agent, and list_agents all return reliability scores/trustDecision, creating overlapping boundaries. The descriptions clarify anonymous vs API-key use, but the duplication still risks misselection.
All tool names follow a consistent snake_case verb_noun pattern: check_agent_trust, get_agent, get_agent_health, list_agents, send_heartbeat. There are no mixed conventions or vague standalone verbs.
Five tools are well-scoped for a pre-invocation trust and reliability service, covering anonymous checking, agent profiles, health, discovery, and owner heartbeat. Each tool earns its place without excessive surface area.
The set covers the core consumer workflows (anonymous trust check, profile lookup, health, discovery) and owner heartbeat, but lacks agent registration/update and batch-check operations. These are minor gaps that agents can work around via other platform paths.
Pre-invocation trust check for an unknown AI agent or MCP server endpoint. 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, agent reliability score (when available), 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 | The exact invocation URL of the agent you're about to call. Used only to look up AgentTrust's own already-observed data for it — this endpoint is never contacted during the check. |
| Name | Required | Description |
|---|---|---|
| name | No | |
| slug | No | |
| status | No | |
| matched | Yes | |
| verified | No | |
| trustDecision | No | |
| reliabilityScore | No | |
| reliabilityScoreStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds high-value behavior beyond them: it does NOT contact endpointUrl during the check (only reads AgentTrust's own monitoring history), and an unregistered URL returns { matched: false } rather than an error. These are exactly the runtime expectations 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries unique information — purpose, auth requirements, lookup semantics, non-contacting behavior, and the error-free miss case. It is front-loaded with the purpose and has no filler or repetition.
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-only lookup with an output schema, the description covers invocation context, auth, no-side-effect guarantees, and the negative-result shape. Nothing material is left for the agent to infer.
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 is already documented in the schema, so the baseline is 3. The description meaningfully reinforces that the URL must be the exact invocation URL and clarifies its role (lookup key only, never contacted), adding a bit of meaning beyond the schema text.
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?
States a specific verb and resource ('Pre-invocation trust check', 'looks up an agent by its exact invocation URL') and enumerates what is returned (status, ownership verification, reliability score, trustDecision). The read-only, lookup-only nature distinguishes it from siblings like get_agent and get_agent_health, which operate on already-known agents.
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?
Clearly scopes usage to 'an unknown AI agent or MCP server endpoint' before invocation, and states it needs no API key or account, which tells the agent it can be called freely. It does not explicitly name or compare against the sibling tools, so it stops short of explicit alternative routing.
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 | |
| source | 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 | |
| reliabilityScoreStatus | Yes | |
| reliabilityScoreComputedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing the returned payload shape (Agent Card, reliability score, trustDecision with recommended/confidence/reasons), which is useful context even though an output schema exists.
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?
A single dense sentence that front-loads the operation and then enumerates the response contents. Every clause serves a purpose, though the return-value enumeration is somewhat heavy for a one-parameter read tool.
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 simple single-parameter read tool with full schema coverage, annotations, and an output schema, the definition is essentially complete. It arguably over-explains return values that the output schema already carries, but nothing an agent needs to call it correctly is missing.
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%, and the slug parameter is fully documented in the schema as the URL slug from a profile or list_agents result. The description only echoes that lookup is by slug, adding no syntax or format detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb (Get) and resource (one AgentTrust agent) qualified by slug, plus what the response contains. It distinguishes itself reasonably from list_agents and get_agent_health by being the single-agent profile fetch, but it never names a sibling explicitly.
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 phrase 'for deciding whether to invoke it' implies the decision-making context, but there is no explicit when-to-use vs when-to-use-alternatives guidance, and check_agent_trust is never mentioned as the likely alternative for trust checks.
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 | |
| reliabilityScoreStatus | Yes | |
| reliabilityScoreComputedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description goes beyond them by explaining how the status is derived — heartbeat freshness for push-mode agents, latest pull check otherwise — and that the result is an 'effective' (computed) status rather than a raw reading. It still omits behavior for unknown slugs or agents that have never reported.
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?
One sentence, front-loaded with the action and resource, with the derivation rule attached as a qualifier rather than padding. Nothing here is wasted.
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?
With an output schema present, the description needn't explain return fields; it only has to identify the resource and the one input, which it does. The push/pull derivation note supplies the extra context a caller needs for a health tool, so nothing material is missing.
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?
There is a single parameter at 100% schema description coverage, so the schema already documents the slug, its source and its length bounds. The description adds no further meaning about the parameter, which matches the baseline of 3 when 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?
States a specific verb and resource ('Get one agent's current effective health status and monitoring detail') and clarifies that the value is computed rather than stored. It does not explicitly distinguish itself from the sibling get_agent, but the 'health status' framing is distinct enough that an agent can pick it out of the sibling list.
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?
Usage is implied — reach for this when you need an agent's health — and the sentence about push-mode vs pull-mode derivation hints at which internal data source feeds the result. There is no explicit when-to-use/when-not statement or named alternative (e.g. 'for raw config use get_agent'), so guidance stays at the implied level.
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. Requires an API key; for an anonymous pre-invocation check use check_agent_trust.
| 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?
Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds valuable context beyond annotations: it requires an API key, explains the trust-check response contents (reliability score, ownership verification, trustDecision), and routes anonymous checks to a sibling. It does not cover rate limits or pagination details, so it falls short of a perfect 5.
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 and compact: it opens with the core purpose, then explains the two modes in three efficient sentences. Every sentence carries useful selection or behavioral information, with no filler 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?
Given the tool's complexity, rich annotations, complete parameter schema, and existing output schema, the description is complete enough. It covers purpose, both invocation modes, authentication, return highlights, and the relevant sibling alternative without needing to duplicate schema or output details.
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 schema already documents limit, cursor, and endpointUrl in detail, including exact matching behavior and empty-list handling. The description reinforces the intent of endpointUrl for trust checking, but adds little semantic detail beyond what the schema already provides. Baseline 3 is appropriate.
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 and resource ('Discover AgentTrust agents' and 'returns the plain paginated listing'), and explicitly distinguishes the tool from sibling check_agent_trust by naming that alternative for anonymous checks. An agent can tell exactly what this tool does and how its two modes differ.
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 gives explicit when-to-use guidance: pass endpointUrl to check trust status before deciding whether to invoke an agent, omit it for a plain public listing, and use check_agent_trust for an anonymous pre-invocation check. Both the primary condition and the alternative route are clearly specified.
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?
Annotations already declare this is a non-read, non-idempotent, non-destructive write. The description adds genuinely new behavioral context beyond that: the server assigns the timestamp and client-supplied time is rejected, which tells the agent what it cannot control. It stops short of explaining the idempotentHint=false consequence (repeated calls recording separate heartbeats).
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?
Two tight sentences, zero filler. The core action and its liveness effect are front-loaded, with the timestamp constraint as a supporting clause.
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 one-parameter write with an output schema and full annotation coverage, the description supplies the essentials: ownership scope, liveness semantics, and server-side timestamp authority. Only idempotency behavior and any rate-limit expectations are left unstated, which is a minor gap.
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 slug parameter is fully documented in the schema, including its source (public profile or list_agents). The description adds only the ownership constraint, so the schema does the heavy lifting and the baseline 3 applies.
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?
States a specific verb and resource ('Record a push-style heartbeat for an agent you own') and clarifies the effect ('marking it alive right now'). This functionally separates it from read-oriented siblings like get_agent_health or check_agent_trust, though no sibling is named explicitly.
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 phrase 'for an agent you own' implies an ownership prerequisite, which is useful context. However, there is no explicit guidance on when to call this versus get_agent_health or how frequently heartbeats should be sent, leaving usage to inference.
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.
get_agent2 fields changedOutput schema / properties / sourceAdded value: +{
+ "enum": [
+ "owner_registered",
+ "externally_observed"
+ ],
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "id",
- "slug",
- "name",
- "description",
- "version",
- "capabilities",
- "status",
- "createdAt",
- "agentCard",
- "verified",
- "ownershipVerifiedAt",
- "reliabilityScore",
- "reliabilityScoreStatus",
- "reliabilityScoreComputedAt",
- "lastCheckedAt",
- "latencyMs",
- "httpStatus",
- "trustDecision"
-]New value: +[
+ "id",
+ "slug",
+ "name",
+ "description",
+ "version",
+ "capabilities",
+ "status",
+ "createdAt",
+ "source",
+ "agentCard",
+ "verified",
+ "ownershipVerifiedAt",
+ "reliabilityScore",
+ "reliabilityScoreStatus",
+ "reliabilityScoreComputedAt",
+ "lastCheckedAt",
+ "latencyMs",
+ "httpStatus",
+ "trustDecision"
+]list_agents2 fields changedOutput schema / properties / agents / items / properties / sourceAdded value: +{
+ "enum": [
+ "owner_registered",
+ "externally_observed"
+ ],
+ "type": "string"
+}Output schema / properties / agents / items / requiredPrevious value: -[
- "id",
- "slug",
- "name",
- "description",
- "version",
- "capabilities",
- "status",
- "createdAt",
- "agentCard",
- "verified",
- "ownershipVerifiedAt"
-]New value: +[
+ "id",
+ "slug",
+ "name",
+ "description",
+ "version",
+ "capabilities",
+ "status",
+ "createdAt",
+ "source",
+ "agentCard",
+ "verified",
+ "ownershipVerifiedAt"
+]check_agent_trust1 field changedOutput schema / properties / reliabilityScoreStatusAdded value: +{
+ "enum": [
+ "none",
+ "fresh",
+ "stale"
+ ],
+ "type": "string"
+}get_agent2 fields changedOutput schema / properties / reliabilityScoreStatusAdded value: +{
+ "enum": [
+ "none",
+ "fresh",
+ "stale"
+ ],
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "id",
- "slug",
- "name",
- "description",
- "version",
- "capabilities",
- "status",
- "createdAt",
- "agentCard",
- "verified",
- "ownershipVerifiedAt",
- "reliabilityScore",
- "reliabilityScoreComputedAt",
- "lastCheckedAt",
- "latencyMs",
- "httpStatus",
- "trustDecision"
-]New value: +[
+ "id",
+ "slug",
+ "name",
+ "description",
+ "version",
+ "capabilities",
+ "status",
+ "createdAt",
+ "agentCard",
+ "verified",
+ "ownershipVerifiedAt",
+ "reliabilityScore",
+ "reliabilityScoreStatus",
+ "reliabilityScoreComputedAt",
+ "lastCheckedAt",
+ "latencyMs",
+ "httpStatus",
+ "trustDecision"
+]get_agent_health2 fields changedOutput schema / properties / reliabilityScoreStatusAdded value: +{
+ "enum": [
+ "none",
+ "fresh",
+ "stale"
+ ],
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "agentId",
- "slug",
- "status",
- "lastCheckedAt",
- "latencyMs",
- "httpStatus",
- "checkStatus",
- "reliabilityScore",
- "reliabilityScoreComputedAt"
-]New value: +[
+ "agentId",
+ "slug",
+ "status",
+ "lastCheckedAt",
+ "latencyMs",
+ "httpStatus",
+ "checkStatus",
+ "reliabilityScore",
+ "reliabilityScoreStatus",
+ "reliabilityScoreComputedAt"
+]list_agents1 field changedOutput schema / properties / agents / items / properties / reliabilityScoreStatusAdded value: +{
+ "enum": [
+ "none",
+ "fresh",
+ "stale"
+ ],
+ "type": "string"
+}check_agent_trust1 field changedInput schema / properties / endpointUrl / descriptionAdded value: +"The exact invocation URL of the agent you're about to call. Used only to look up AgentTrust's own already-observed data for it — this endpoint is never contacted during the check."check_agent_trustget_agentget_agent_healthlist_agentssend_heartbeatCheck any x402 endpoint before your AI agent pays it: trust grade, verdict, and hijack checks.
Scores how well AI agents will use your API, 0-100, from its OpenAPI spec. Free and read-only.
Check an x402 endpoint before your agent pays it: avoid / caution / ok, proven on-chain.
Pay-per-call safety checks for AI agents: screen a crypto address or URL before you transact.
Add one secure layer between your agents and this server.
