Monitoring for the agent economy — liveness, latency, trust scoring for MCP endpoints
Scored across 8 tools
Each monitoring tool targets a distinct action: census summary, endpoint listing, dead alerts, one-off probing, and watchlist addition. The two skill tools are clearly separate from the monitoring domain and from each other.
Most tools share the aw_ prefix, but the pattern is inconsistent: some are noun-style (aw_alerts, aw_census) while others are verb-style (aw_check_endpoint, aw_list_monitored). The skill tools break the prefix pattern entirely, though all names remain readable.
Eight tools is well within the ideal range and appropriate for a monitoring-focused server. Each tool contributes to either the endpoint monitoring workflow or the product skills workflow without feeling redundant.
The server covers census, listing, alerting, one-off checks, and adding watchlist entries, but lacks lifecycle tools for managing that watchlist, such as removing endpoints or listing current watchlist members. This creates a notable dead end for the add-to-watch workflow.
Show dead endpoints across the monitored registry (alive=false).
Returns up to 500 dead endpoints with names. Use after aw_census or
aw_list_monitored to get the actionable dead list. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that it is read-onlyhare and returns up to 500 dead endpoints, which is useful context about output limits and the type of data, but it doesn't mention pagination or error handling, which could be relevant given the 500 cap.
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 concise, with three sentences, and front-loads the core purpose. The usage guidance and read-only note are placed efficiently without redundancy. Every sentence serves a purpose: what it does, what it returns, and when to use it.
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 has no parameters and no output schema, the description provides essential information: the purpose, the output limit, and the usage order relative to siblings. It doesn't specify the exact format of the output (e.g., list of names) but that may be inferred. It is fairly complete for a simple read-only tool, though explicit output format would improve it.
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 are no parameters in the schema, so the baseline is 4. The description adds context about the output (dead endpoints, names) and the limit of 500, which helps the agent understand what to expect without needing parameters. It doesn't need to explain parameters since none exist.
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 shows dead endpoints (alive=false) from the monitored registry, using a specific verb and resource. It distinguishes itself from sibling tools by specifying it provides the actionable dead list, while others like aw_census or aw_list_monitored likely provide broader views.
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 says to use this tool after aw_census or aw_list_monitored to get the actionable dead list, providing a clear usage sequence and differentiating it from those siblings. This gives the agent direct guidance on when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-census summary of the official MCP registry: 7,454 endpoints probed with real MCP handshakes.
Returns alive/dead/unknown counts and percentages. States: alive = MCP
initialize succeeded; dead = no answer; unknown = answered but auth-gated
(401/403/402) or redirecting — liveness unprovable without credentials.
Use to quantify how much of the MCP ecosystem is actually reachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the probing method ('real MCP handshakes'), defines each liveness state, and discloses that 'unknown' results are auth-gated or redirecting with liveness unprovable without credentials. This adds meaningful behavioral context beyond the readOnly/idempotent/destructive annotations.
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 concise and front-loaded: it opens with the core purpose, then gives return details, state definitions, and a practical use case. Every sentence contributes value without 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 parameterless tool with no output schema, the description is complete. It explains what the tool returns, how the data was gathered, how to interpret the three states, and why some results remain unknown. Nothing essential is missing for an agent to select and invoke it 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 tool has zero parameters and the schema coverage is 100%, so the baseline of 4 applies. The description adds no parameter-specific meaning, which is appropriate since there are none to document.
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: a full-census summary of the official MCP registry, returning alive/dead/unknown counts and percentages. The term 'full-census' clearly distinguishes it from siblings like aw_check_endpoint or aw_health, which focus on individual endpoints or narrower scopes.
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 says 'Use to quantify how much of the MCP ecosystem is actually reachable,' giving a clear use case. It does not explicitly name alternatives or exclusion conditions, but the full-census framing and sibling names make the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Probe an MCP or HTTP-402 endpoint now and get its trust verdict.
Performs a real MCP initialize handshake (not a ping), measures p50/p95
latency, counts tools, hashes the tool schema (for drift detection), and
checks RFC 9728 auth metadata. Returns: alive (bool), name, tool_count,
latency_p50_ms, tool_schema_hash, auth_metadata_present, and error detail
when dead. Use before wiring any new MCP server into your client.
Args:
url: the MCP or HTTP-402 endpoint URL to probe (e.g. https://host/mcp/)
timeout: probe timeout in seconds (default 30)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds substantial behavioral context beyond that: it performs a real MCP initialize handshake, measures p50/p95 latency, counts tools, hashes the tool schema for drift detection, checks RFC 9728 auth metadata, and returns error detail when dead. This fully discloses what happens when the tool is invoked.
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 core purpose, then supplies behavior, return values, usage, and arguments in a clear, organized structure. It is dense but every sentence earns its place; there is 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?
For a two-parameter probe tool with no output schema, the description is complete: it covers what the tool does, when to use it, how it behaves, what it returns, and what each argument means. The only minor ambiguity is that p95 latency is mentioned as measured but not listed in the return fields, but the explicit return list resolves most agent uncertainty.
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 carries the full burden for explaining parameters. It does this well: url is described as the MCP/HTTP-402 endpoint URL with an example, and timeout is described with units and default value. Both parameters receive meaningful semantic context beyond the raw schema.
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 opens with a specific verb and resource: 'Probe an MCP or HTTP-402 endpoint now and get its trust verdict.' It then details exactly what the probe does (initialize handshake, latency, tool count, schema hash, auth metadata), clearly distinguishing it from monitoring or alerting siblings.
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?
Provides explicit usage guidance: 'Use before wiring any new MCP server into your client.' The 'not a ping' clarification also prevents misuse. It does not explicitly name sibling alternatives or contraindications, but the stated use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liveness check for the Agent Watch API. Returns ok, service name, and version. Call this first to verify connectivity before using other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds that it returns status information, which is consistent and transparent about the operation's effect.
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 sentences, direct and to the point. No redundant words or unnecessary details. The structure front-loads the purpose and ends with usage guidance.
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 liveness check with no parameters and no output schema, the description covers the purpose, the return contents, and the recommended call sequence. Nothing essential 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?
The tool has no parameters, so the schema coverage is trivially complete. The description does not need to explain any inputs, and the baseline for zero parameters is 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?
Clearly states it is a liveness check for the Agent Watch API, and describes the returned fields (ok, service name, version). The phrase 'before using other tools' implies a distinct role from sibling tools.
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?
Explicitly instructs to call this first to verify connectivity before using other tools, providing a clear when-to-use directive and implicitly when not to use (for other operations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all endpoints in the Agent Watch census with their registry names.
Returns count and the full endpoint list (URLs). Combine with aw_alerts
to find which of these are dead. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by describing the return contents (count and URL list) and the suggested workflow with aw_alerts. It does not mention pagination, rate limits, or auth, but for a zero-parameter list operation this is a minor gap.
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?
Three sentences with no waste: the action comes first, followed by return contents, then a practical use case. 'Read-only' repeats the annotation, but it is short and does not bloat the description.
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 zero-parameter, read-only listing tool with annotations already covering safety, the description fully equips an agent: it defines scope, output, and how to use it alongside a sibling tool. No output schema exists, so the explicit mention of 'count' and 'URLs' is important and present.
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 are no parameters and schema description coverage is 100%, so no parameter documentation is needed. The description's mention of 'registry names' and 'full endpoint list (URLs)' gives context about what the returned data will contain, which is sufficient for an empty-schema tool.
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 ('List'), a resource ('endpoints in the Agent Watch census'), and the key output ('registry names', 'full endpoint list (URLs)'). The sentence about combining with aw_alerts helps an agent understand what this tool is not—the alert-based view of endpoint status.
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 a clear usage context: list all monitored endpoints and combine with aw_alerts to find dead endpoints. It does not explicitly enumerate when to use aw_census, aw_check_endpoint, or aw_health, but the intended use case is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add endpoints to your personal watchlist (probed immediately, then every 6h).
Plan-limited by the email used at checkout: free 5, Builder ($19/mo) 50,
Team ($99/mo) 500 endpoints. Alerts fire on alive→dead transitions and
tool-schema drift. Already-watched URLs are returned without re-probing.
Args:
email: the email your subscription is under (free tier works too)
urls: endpoint URLs to add to your watchlist
watch_token: issued at registration, delivered in your onboarding email — required
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| Yes | |||
| watch_token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it explains immediate probing, periodic re-probing, alert conditions, plan-based quotas, required watch_token auth, and idempotent behavior for already-watched URLs. No contradiction with idempotentHint=true or destructiveHint=false.
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?
Dense but economical: purpose, behavior, plan limits, alert semantics, and parameters are covered in a few sentences with no filler. The most important information is front-loaded.
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?
Covers the main API contract: what the tool does, when it runs, what triggers alerts, plan constraints, and required token. It does not specify quota-exceeded behavior or detailed response shape, but this is still a well-specified tool description.
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 0%, but the Args section compensates by explaining all three parameters: email identifies the subscription/plan, urls are the endpoints to watch, and watch_token is required for the operation. It lacks format details for URLs, but the core meaning is clear.
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 opens with a specific verb and object: 'Add endpoints to your personal watchlist.' It clearly distinguishes this from one-off checks and explains the monitoring behavior, so an agent can immediately identify the tool's purpose.
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 provides clear context: this tool adds endpoints to a watchlist that are probed immediately and then every 6 hours, with alerts on state changes. It does not explicitly contrast with sibling tools like aw_check_endpoint, so it stops short of full when-to-use versus when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a product skill file by its skill:// URI.
Args:
uri: e.g. skill://<product>/<skill-name>/SKILL.md
Get valid URIs from `skills_list_tool`.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The word 'Read' makes the read-only nature apparent and the URI format is useful, but it does not describe the return value, failure behavior, or any edge cases. This is adequate but not rich.
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 short and front-loaded: the purpose appears first, followed by the only relevant argument detail. The Args block is not redundant because it adds the URI format example beyond the bare schema.
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 operation, the description provides the URI syntax and tells the agent how to discover valid URIs, so invocation is straightforward. A brief note about the return content would make it fully complete, but the current description leaves few gaps.
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's uri property has no description, so the description must compensate. It does by providing a concrete URI pattern and an authoritative source for valid values. This covers the parameter's meaning well despite 0% schema 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 first sentence states the verb and resource clearly: 'Read a product skill file by its skill:// URI.' It identifies the exact resource type and URI scheme. It does not explicitly contrast itself with skills_list_tool, but pointing to it for valid URIs makes the relationship understandable.
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 instruction 'Get valid URIs from skills_list_tool' tells the agent the prerequisite step and names the relevant sibling tool for discovery. It does not spell out when not to use read_skill, but it gives enough context to infer the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this product's skills. Each entry carries the SKILL.md URI,
its name and description, verbatim frontmatter, and a per-file
sha256 manifest. Read a body with read_skill.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that each entry includes a sha256 manifest, implying integrity verification, and that it returns metadata (URI, name, description, frontmatter) rather than the full body. It explicitly points to read_skill for reading the body, which clarifies that this tool does not return bodies. This is good behavioral context beyond the schema.
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 concise, only two sentences, but it packs significant detail: the resource, the list of fields in each entry, and a pointer to the sibling tool. It is appropriately sized and front-loaded with the core purpose. Minor redundancy like 'verbatim frontmatter' could be trimmed but adds precision, so it's fine.
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 that the tool has no parameters and no output schema, the description does a good job of explaining what the tool returns. It covers the entry content (URI, name, description, frontmatter, sha256) and the limitation that it does not return the body. Enough for an agent to know what to expect. Missing details like whether pagination or sorting exist, but for a simple list tool, it's adequately complete.
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 tool has no parameters, so the schema provides no semantic guidance. The description fully compensates by clearly stating what the output contains, which is effectively the semantics of the tool's result. Since the tool takes no input, the description's explanation of the output serves as the primary semantic information for the agent.
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 purpose: to list the product's skills and enumerates the exact content of each entry (SKILL.md URI, name, description, frontmatter, sha256 manifest). This distinguishes it from the sibling 'read_skill' which is for reading a skill's body. However, it could be more specific about the 'product' context, but it's sufficiently clear.
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 the primary use case: when you need an overview of available skills. It explicitly mentions the alternative, 'read_skill', for reading a skill's body, which serves as a clear contrast. It doesn't explicitly state when NOT to use it, but the mention of read_skill provides a functional distinction.
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.
read_skillskills_list_toolaw_watch1 field changedInput schema / properties / watch_tokenAdded value: +{
+ "default": "",
+ "title": "Watch Token",
+ "type": "string"
+}aw_alertsaw_censusaw_check_endpointaw_healthaw_list_monitoredaw_watchMCP-native Trust Infrastructure for AI Agents. Persistent encrypted memory with Trust Quotient.
MCP observability. Query live traffic, errors, duration, and alerts from your AI agent.
Agent-native crypto market-data over MCP+REST: order flow, whales, liquidations, calibrated scores
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Add one secure layer between your agents and this server.
