Agentic feedback
An agent that hits a broken tool has no support channel. It cannot open a ticket, and it will usually just stop trying, so the failure reaches you as nothing more than a status code in a log. Elva closes that loop: every hosted MCP server carries a built-in way for the calling agent to tell you, in its own words, what it expected and what it actually got.
A tool you did not put in your spec
Alongside the tools generated from your OpenAPI operations, every deployment exposes one reserved tool: give_feedback. It is a diagnostic channel, not part of your API surface. Agents are instructed to reach for it only after one of your other tools has already returned something wrong, never for questions about how a tool works, and never twice for the same problem.
It is deliberately inert. Calling it does not retry the failed call, does not change data, and does not reach your API at all. It writes a report and stops. An agent that files one is told to say the problem was logged, never to imply it is fixed.
What the agent reports
Each report names the tool involved, what the agent expected, what actually happened, and a best-guess category:
error_response: your API returned an error.timeout: no response came back in time.wrong_result_shape: the response did not match what the tool's schema promised.auth_failed: a 401, 403, or similar.other: anything else the agent could not classify.
The agent is also asked to summarize the failure rather than paste raw payloads. Responses can carry your own customers' data, and a report is not the place for it.
What lands in your workspace
Three things turn a pile of reports into a queue you can actually work through.
Status
Every report is open, reviewed, or resolved, so triage state lives on the report rather than in someone's head.
Critical flag
Raised when the agent got nothing usable at all: an auth failure, a timeout, or a 5xx from your API.
Date range
Filter to a window, so a spike in reports can be lined up against the deploy that caused it.
Alongside those, each report carries the tool involved with its HTTP method and path, and the agent that filed it, so a report points at a specific operation rather than at your API in general.
The status code and latency on a report are the gateway's, not the agent's. Elva attaches them from its own record of the failed call, so a report cannot be skewed by a model guessing at numbers it never saw. Feedback is also rate-limited per deployment and is not metered as a tool call, so an agent reporting a problem never eats into your monthly quota.
You see the reports an agent blamed on your API. When the agent points at Elva's own runtime instead, or cannot tell which side failed, the report goes to Theneo rather than into your workspace. This view is deliberately a list of problems you can act on, not a window into our infrastructure.
Where to go next
On this page
- Agentic feedback