NotWorking

Report an access path failure

report

Report that an access path failed for you. Use the access-path id from check_status, or the URL you used. Only report failures that came from the service, not ones caused by your own tools, permissions or settings (like a fetch tool that refuses a domain). Anonymous. Never include personal data, booking details, credentials or full URLs with query strings. target is which access path failed; what_failed is how, from this list (the same for every service): site_unreachable: The site or server could not be reached at all, for example a DNS error, a timeout or a 5xx server error.; bot_block: The service refused the agent: an access-denied page, a 403 or 429 error, a bot wall or a challenge page.; robots_disallow: The site's robots.txt asks automated agents not to fetch this page.; captcha: A CAPTCHA or 'are you human?' check stopped the agent.; login_auth: Logging in or authenticating failed, for example a login loop, a new login step or rejected credentials.; api_error: An API the agent used returned an error or an unexpected response.; mcp_error: An MCP server failed to connect, initialise, list its tools or run a tool.; skill_failed: A skill could not be installed, or it ran but errored or produced a wrong result.; payment: A payment or checkout step failed or was blocked.; specific_page: One particular page or step failed while the rest of the service seemed to work.; other: Something else went wrong.

Input Schema

Name	Required	Description
`note`	No	Optional, at most 280 characters, no personal data. Never shown to other agents.
`type`	No	Optional: site, route, mcp or skill. Use mcp for an MCP server that isn't in the catalogue, since its name can look like a domain
`target`	Yes	The access-path id (or URL) you used
`country`	No	Optional ISO-3166 alpha-2 country code, like SG
`agent_type`	No	Optional: which agent you are; 'other' if not listed
`what_failed`	Yes	How it failed: one or more values

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026

changedInput schema / properties / what_failed / items / enum

Previous value: -[
-  "site_unreachable",
-  "bot_block",
-  "captcha",
-  "login_auth",
-  "api_error",
-  "mcp_error",
-  "skill_failed",
-  "payment",
-  "specific_page",
-  "other"
-]New value: +[
+  "site_unreachable",
+  "bot_block",
+  "robots_disallow",
+  "captcha",
+  "login_auth",
+  "api_error",
+  "mcp_error",
+  "skill_failed",
+  "payment",
+  "specific_page",
+  "other"
+]

Changed9 schema fields changedOct 9, 2026

removedInput schema / properties / outcome

Removed value: -{
-  "description": "failed or success",
-  "enum": [
-    "failed",
-    "success"
-  ],
-  "title": "Outcome",
-  "type": "string"
-}

addedInput schema / properties / type

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "site",
+        "route",
+        "mcp",
+        "skill"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional: site, route, mcp or skill. Use mcp for an MCP server that isn't in the catalogue, since its name can look like a domain",
+  "title": "Type"
+}

removedInput schema / properties / what_failed / anyOf

Removed value: -[
-  {
-    "items": {
-      "enum": [
-        "site_unreachable",
-        "bot_block",
-        "captcha",
-        "login_auth",
-        "api_error",
-        "mcp_error",
-        "skill_failed",
-        "payment",
-        "specific_page",
-        "other"
-      ],
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / what_failed / default
```
Removed value: -null
```

changedInput schema / properties / what_failed / description

Previous value: -"Required when outcome is failed: one or more values"New value: +"How it failed: one or more values"

addedInput schema / properties / what_failed / items

Added value: +{
+  "enum": [
+    "site_unreachable",
+    "bot_block",
+    "captcha",
+    "login_auth",
+    "api_error",
+    "mcp_error",
+    "skill_failed",
+    "payment",
+    "specific_page",
+    "other"
+  ],
+  "type": "string"
+}

addedInput schema / properties / what_failed / minItems
```
Added value: +1
```
addedInput schema / properties / what_failed / type
```
Added value: +"array"
```

changedInput schema / required

Previous value: -[
-  "target",
-  "outcome"
-]New value: +[
+  "target",
+  "what_failed"
+]

First observedOct 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare the write/safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower, yet the description still adds substantive behavior: the submission is anonymous, must never contain personal data, booking details, credentials or query-string URLs, and the note is never shown to other agents. It stops short of describing confirmation, deduplication or any rate limit on repeated reports, leaving a small gap.

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?

Purpose and privacy constraints are front-loaded, and the long enum glossary is load-bearing because the schema supplies no value descriptions. It is dense rather than bloated, though the inline enumeration is bulkier than ideal and could have been trimmed given some values are self-explanatory.

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 six parameters, a write operation and an output schema already present, the description covers the remaining agent-facing questions: where the target comes from, what each failure code means, the privacy/anonymity rules, and the failure-source exclusion. Nothing needed to call this correctly is missing.

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%, so the baseline is 3, but the description genuinely exceeds the schema by defining every what_failed enum value ('site_unreachable: ...', 'bot_block: ...') which the schema lists without per-value text, and by clarifying that target is 'which access path failed' and can be an id or URL. That is real added meaning, though the optional note/type/country/agent_type parameters are largely left to their schema descriptions.

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 first sentence states a specific verb and resource — 'Report that an access path failed for you' — and the rest of the text pins down exactly what an 'access path failure' means. It is easily distinguished from its sibling check_status, which it explicitly names as the source of the id it consumes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It tells the agent precisely when to file a report ('use the access-path id from check_status, or the URL you used') and, unusually for this kind of tool, when NOT to — failures caused by the agent's own tools, permissions or settings, with a concrete counterexample ('a fetch tool that refuses a domain'). Nothing is left to inference.

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

All NotWorking tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.