Skip to main content
Glama
Sign In

Ahel

by ai.ahel
OverviewDiscussionsAdmin

Rate a run or report a problem

feedback

Rate one run or one catalog request of this workspace good or bad, or, with no id, report anything about Ahel: confusing results or charges, unclear instructions, unhelpful errors, a workaround you needed. Report small annoyances too, even when the task succeeded, each issue once. Ahel reads every note to fix providers and the catalog. Leave out private information, keys and raw responses. Free; changes nothing else. NOT for: reading a run's state or rows, which is capability_run_status, or asking for a missing task, which is catalog_request.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoTo rate one: an execution id from run_capability, or a request id from catalog_request.
noteNoWhat was right or wrong, in a sentence or two. Required with no id.
ratingNoWith id: good or bad.
categoryNoWith no id: quality (results), pricing (charges or prices), friction (using Ahel) or other.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / category
      Added value: +{
+  "description": "With no id: quality (results), pricing (charges or prices), friction (using Ahel) or other.",
+  "enum": [
+    "quality",
+    "pricing",
+    "friction",
+    "other"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / id / description
      Previous value: -"An execution id from run_capability, or a request id from catalog_request."New value: +"To rate one: an execution id from run_capability, or a request id from catalog_request."
    • changedInput schema / properties / note / description
      Previous value: -"Optional: what was right or wrong, in a sentence or two."New value: +"What was right or wrong, in a sentence or two. Required with no id."
    • changedInput schema / properties / rating / description
      Previous value: -"good or bad."New value: +"With id: good or bad."
    • removedInput schema / required
      Removed value: -[
-  "id",
-  "rating"
-]
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare the write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower, but the description still adds real context: it is free, it 'changes nothing else', notes are read by Ahel to fix providers, issues should be filed once, and private data/keys/raw responses must be excluded. That privacy and dedup guidance is not derivable from the annotations.

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 is front-loaded in the first clause, followed by the no-id mode, then exclusions — a sensible ordering. It runs long and the middle clause enumerating example complaints plus 'report small annoyances too' is slightly padded, though each sentence carries some guidance.

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 four-optional-parameter write tool with no output schema, the description covers modes, exclusions, cost, side effects, and data-handling hygiene. Nothing an agent needs in order to call it correctly is missing.

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 coverage is 100% and the enum descriptions already explain that rating applies with an id and category applies without one, so this is baseline territory. The description reinforces the two-mode coupling but adds no syntax or constraint beyond what the schema states.

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?

States a specific verb pair (rate / report) with the exact resources (one run, one catalog request) and explicitly branches on the presence of an id. An agent can distinguish this from review or capability_run_status without opening any schema.

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?

Gives the when-to-use conditions for both modes ('with no id, report anything about Ahel') and an explicit exclusion list naming the correct alternatives: capability_run_status for reading a run's state, catalog_request for a missing task. It even lowers the bar for use ('report small annoyances too, even when the task succeeded').

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

All Ahel toolsInspect
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.

Resources