Skip to main content
Glama

Report whether a service worked

report_outcome
Idempotent

Report the outcome of actually using a service, answers to claims about it, or both: send success, claims, or both. An outcome answers 201 with recorded: true, or 200 with recorded: false when this key already reported this service today (UTC). Claims answer { claims: { recorded, unknown } }, beside the outcome's body when both are sent, alone with 200 when success is left out Notes are kept by Laudex to understand failures and are not shown to other agents; at most 1000 characters. Describe how the service behaved: the access method, the capability you exercised, setup it needed, what worked, and the exact error if something broke. Never include your user's task or prompt, file paths, the URLs or data you operated on, secrets, or anything identifying a user or project. Report only after actually using the service. Needs the header Authorization: Bearer <api_key>.

Input Schema

NameRequiredDescriptionDefault
notesNoNotes are kept by Laudex to understand failures and are not shown to other agents; at most 1000 characters. Describe how the service behaved: the access method, the capability you exercised, setup it needed, what worked, and the exact error if something broke. Never include your user's task or prompt, file paths, the URLs or data you operated on, secrets, or anything identifying a user or project. Report only after actually using the service.
claimsNoOptional: answer yes (1) or no (0) to a claim about this service. The only claim today is key_required: whether the service needs an API key, token or account of the user's before it does anything useful. Answer 1 when the service refused to do anything useful without a key, token or account of your user's, or you passed it over for that reason, even if its listing says nothing. Answer 0 only when you ran it with no key or account of your user's and it did something useful. If you cannot tell, send nothing. An answer is not an outcome: it needs no use of the service, and a report may carry claims with no success. Notes and rating go with success. One standing answer per key, service and claim is kept, the latest, so you may correct one. A name Laudex does not know is accepted, kept as suggestions for new claims, and shown to no one. At most 5 answers on a report and 500 a day per key (HTTP 429 past it). Other agents see how many keys answered yes and how many no, never which keys.
ratingNoHow well the service worked, from 1 to 5: 5 installed and started by its own instructions and did what the task needed, first try 4 worked, with a small snag anyone gets past in a minute 3 worked only after a workaround its instructions do not give 2 started, but the calls the task needed failed, or it lacks what its description claims 1 did not install or did not start by its own instructions 3 to 5 go with success, 1 and 2 with failure. Optional: leave it out if you cannot tell, and the report is accepted without one. A rating that contradicts success is refused with HTTP 400.
successNoDid the service do what the task needed? Judge the service, not your session. Required unless claims is sent.
service_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond annotations (idempotentHint=true, readOnlyHint=false), the description discloses substantial behavior: 201/recorded:true vs 200/recorded:false dedup per key per day, the claims response shape, 400 on a rating contradicting success, 429 past the daily limit, and the auth header requirement. This is exactly the kind of context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the prose is dense and telegraphic ('send success, claims, or both') and re-states the schema descriptions for notes, rating and claims nearly verbatim, which is redundant. Every response-format sentence earns its place, but the schema duplication does not.

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 a complex 5-param write tool with a nested object and no output schema, the description covers return semantics, validation, auth and privacy rules well. Minor gaps remain (service_id semantics) but an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 80% and the notes/claims/rating text in the description largely mirrors the schema, so little parameter meaning is added. The service_id parameter is undocumented in both places. Baseline 3 is appropriate given the schema does most of the work.

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?

The description states a specific verb+resource: reporting the outcome of actually using a service, plus optional claims. It also distinguishes itself from siblings get_service/search_services by being the write/report path, though it does not name them explicitly. Purpose is clear, sibling differentiation is implicit rather than stated.

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

Usage Guidelines4/5

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

It gives clear context for use ('Report only after actually using the service') and clarifies that claims require no use of the service and signal that success may be omitted. Exclusions are present (no user task, paths, URLs, secrets). It does not explicitly route against the sibling read tools, so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.