Agent Help Network

rate_last_lookup

Idempotent

If an earlier check_incident answer gave you a feedback token and you then tried again, say whether it worked. Sends only the token and the outcome code, no hostname. outcome: succeeded (the next attempt worked), still_blocked, handed_off (you handed the step to the user) or gave_up. path: official_path (you used the official path the answer pointed to), same_site (you retried the same site) or unknown. A token works once and expires one hour after the lookup; do not send one for an attempt you did not make. The outcome is counted anonymously per host and hour and does not change any answer.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "token": "<token>",
      "outcome": "<outcome>"
    },
    "name": "rate_last_lookup"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No	Which way that attempt went: official_path (you used the official path the answer pointed to), same_site (you retried the same site) or unknown (the default).	unknown
`token`	Yes	The feedback_token.token value from the check_incident answer, unchanged.
`outcome`	Yes	What happened on your next attempt: succeeded (it worked), still_blocked, handed_off (you handed the step to the user) or gave_up.

Output Schema

Name	Required	Description	Default
`accepted`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 10, 2026

addedInput schema / properties / outcome / description

Added value: +"What happened on your next attempt: succeeded (it worked), still_blocked, handed_off (you handed the step to the user) or gave_up."

addedInput schema / properties / path / description

Added value: +"Which way that attempt went: official_path (you used the official path the answer pointed to), same_site (you retried the same site) or unknown (the default)."

AddedOct 31, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Beyond the annotations, it discloses token single use and expiry, anonymous per-host/hour counting, hostname exclusion, and that feedback does not change any answer. However, “Sends only the token and the outcome code” is imprecise because the schema also permits the optional path parameter.

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?

The conditional opening front-loads the selection criteria, followed by payload, value, lifecycle, and consequence details. Repeating both enum explanations despite full schema coverage adds some avoidable bulk.

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?

For a simple three-parameter feedback tool, it covers prerequisites, outcome and path selection, token validity, privacy and aggregation behavior, and the lack of effect on answers. The output schema removes the need to explain return values, while the optional-path payload ambiguity is minor and resolvable from the input schema.

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%, and the outcome and path explanations largely repeat the already documented enums. The description nevertheless adds useful token semantics: it works once, expires one hour after lookup, and must correspond to an attempt actually made.

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 description specifies the action—report whether a subsequent attempt worked—and the exact prerequisite, a feedback token from an earlier check_incident answer. Its post-retry feedback scope clearly differentiates it from performing the original incident lookup.

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 explicitly says to use the tool only after receiving a token and making another attempt, and says not to submit feedback for an attempt that was not made. Single-use and one-hour expiry rules further clarify when a submission is valid.

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

All Agent Help Network tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.