Physical Capability Cloud

pcc_report

Report a bug, friction, or dead-end you hit while using PCC. Call this the moment you get stuck and cannot recover: a 5xx (its response carries a report_hint with pre-filled fields), a 4xx you cannot fix from its message, the same step failing twice, or a misleading tool/description. PUBLIC — works before you provision an API key (cold agents are exactly who this is for). Persisted durably and reviewed by the PCC team. Report each distinct failure ONCE; never include an API key, token, or wallet secret. Rate-limited per IP.

Input Schema

TableJSON Schema

Name	Required	Description
`logs`	No	Optional but valuable: your last few steps as SUMMARIES (never full request/response bodies) — the sequence that led to the failure. Secrets are never allowed in a note.
`type`	No	bug = something is broken/wrong; friction = it works but was confusing/harder than it should be; idea = a suggestion or missing capability. Defaults to bug.
`detail`	No	Multi-line context: the full error body, what you tried, what you expected. Optional but recommended.
`method`	No	The HTTP method you used. From `report_hint.send.method`. Example: 'POST'.
`status`	No	The HTTP status you got. From `report_hint.send.status`. Example: 500.
`agentId`	No	Which model/agent you are. Example: 'claude', 'gpt-4o', 'gemini'. Optional.
`summary`	Yes	1-line description of what you were doing and what went wrong. Example: 'POST /api/build/contract returned 500 with no hint about the missing field.'
`traceId`	No	Your journey ID — returned by provision_api_key and on every response as `x-pcc-trace-id` (also in a 5xx `report_hint.traceId`). Lets PCC replay your full run.
`endpoint`	No	The route you were on when you got stuck. From a 5xx `report_hint.send.endpoint`. Example: '/api/build/contract'.
`severity`	No	How badly this blocked you. Optional.
`errorCode`	No	The machine error code from the response body, if any. From `report_hint.send.errorCode`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed18 schema fields changedSep 30, 2026

addedInput schema / properties / agentId

Added value: +{
+  "description": "Which model/agent you are. Example: 'claude', 'gpt-4o', 'gemini'. Optional.",
+  "type": "string"
+}

removedInput schema / properties / agent_kind

Removed value: -{
-  "description": "Which model / agent you are. Example: 'claude', 'gpt-4o', 'gemini', 'canary'.",
-  "maxLength": 200,
-  "type": "string"
-}

removedInput schema / properties / confused_about

Removed value: -{
-  "description": "Free-form category — which onboarding stage tripped you up. Example: 'auth', 'discovery', 'build', 'fund', 'submit', 'settle'.",
-  "maxLength": 200,
-  "type": "string"
-}

changedInput schema / properties / detail / description

Previous value: -"Multi-line context: full error code, what you tried, what you expected. Optional but recommended."New value: +"Multi-line context: the full error body, what you tried, what you expected. Optional but recommended."

changedInput schema / properties / detail / maxLength
```
Previous value: -4000New value: +20000
```

addedInput schema / properties / endpoint

Added value: +{
+  "description": "The route you were on when you got stuck. From a 5xx `report_hint.send.endpoint`. Example: '/api/build/contract'.",
+  "type": "string"
+}

addedInput schema / properties / errorCode

Added value: +{
+  "description": "The machine error code from the response body, if any. From `report_hint.send.errorCode`.",
+  "type": "string"
+}

removedInput schema / properties / last_endpoint

Removed value: -{
-  "description": "The route you were on when you got stuck. Example: '/api/build/contract'.",
-  "maxLength": 200,
-  "type": "string"
-}

removedInput schema / properties / last_error_code

Removed value: -{
-  "description": "The error code from the Result<T> envelope you received, if any. Example: 'BAD_REQUEST', 'CAPABILITY_NOT_FOUND'.",
-  "maxLength": 200,
-  "type": "string"
-}

addedInput schema / properties / logs

Added value: +{
+  "description": "Optional but valuable: your last few steps as SUMMARIES (never full request/response bodies) — the sequence that led to the failure. Secrets are never allowed in a note.",
+  "items": {
+    "properties": {
+      "method": {
+        "description": "HTTP method, e.g. POST.",
+        "type": "string"
+      },
+      "note": {
+        "description": "One line on what happened at this step.",
+        "maxLength": 500,
+        "type": "string"
+      },
+      "path": {
+        "description": "Route, e.g. /api/build/price.",
+        "type": "string"
+      },
+      "status": {
+        "description": "HTTP status you got.",
+        "type": "integer"
+      },
+      "step": {
+        "description": "1-based step index.",
+        "type": "integer"
+      }
+    },
+    "type": "object"
+  },
+  "maxItems": 20,
+  "type": "array"
+}

addedInput schema / properties / method

Added value: +{
+  "description": "The HTTP method you used. From `report_hint.send.method`. Example: 'POST'.",
+  "type": "string"
+}

addedInput schema / properties / severity

Added value: +{
+  "description": "How badly this blocked you. Optional.",
+  "enum": [
+    "low",
+    "medium",
+    "high",
+    "critical"
+  ],
+  "type": "string"
+}

addedInput schema / properties / status

Added value: +{
+  "description": "The HTTP status you got. From `report_hint.send.status`. Example: 500.",
+  "type": "integer"
+}

changedInput schema / properties / summary / description

Previous value: -"1-line description of what went wrong. Example: 'Build options endpoint returned 500 with no hint about what was missing.'"New value: +"1-line description of what you were doing and what went wrong. Example: 'POST /api/build/contract returned 500 with no hint about the missing field.'"

changedInput schema / properties / summary / maxLength
```
Previous value: -280New value: +5000
```

addedInput schema / properties / traceId

Added value: +{
+  "description": "Your journey ID — returned by provision_api_key and on every response as `x-pcc-trace-id` (also in a 5xx `report_hint.traceId`). Lets PCC replay your full run.",
+  "type": "string"
+}

removedInput schema / properties / trace_id

Removed value: -{
-  "description": "Your onboarding journey ID. Returned by provision_api_key (body field) and present on every response as the `x-pcc-trace-id` header.",
-  "pattern": "^tr_[0-9a-f]{16,32}$",
-  "type": "string"
-}

addedInput schema / properties / type

Added value: +{
+  "description": "bug = something is broken/wrong; friction = it works but was confusing/harder than it should be; idea = a suggestion or missing capability. Defaults to bug.",
+  "enum": [
+    "bug",
+    "friction",
+    "idea"
+  ],
+  "type": "string"
+}

First observedJul 13, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the rest and does so richly: it is PUBLIC and works before API-key provisioning, reports are persisted durably and reviewed by the PCC team, and the endpoint is rate-limited per IP. It also points to the report_hint payload that pre-fills fields from a 5xx.

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?

Front-loads the purpose, then the trigger conditions, then operational constraints in a compact block with zero filler. It is dense — a few clauses could be split for readability — but every sentence carries load.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter write tool with no output schema, the description covers when to use it, the security constraints, dedupe behavior, and rate limiting. It does not say what the call returns (e.g. a report ID) or confirm the minimum viable submission, which is a minor gap given no output schema exists to explain the response.

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 adds real value: it explains that endpoint/method/status/errorCode come from the `report_hint.send.*` fields of a 5xx or from `x-pcc-trace-id` for traceId, which the schema alone does not tie together. The secrets prohibition also constrains the logs/note parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Report a bug, friction, or dead-end') and clearly scopes it to failures encountered while using PCC. It does not explicitly differentiate itself from nearby siblings like report_anomaly, report_protocol_failure, submit_feedback, or send_diagnostics, so it falls short of the top tier.

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?

Enumerates concrete trigger conditions — a 5xx, an unfixable 4xx, the same failure twice, or a misleading tool/description — plus a dedupe rule ('report each distinct failure ONCE') and a prohibition (never include secrets). An agent knows exactly when to call this and when to stop.

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

All Physical Capability Cloud 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.

pcc_report

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources