Skip to main content
Glama

Edge Skills: rate a loaded skill

rate_skill
Idempotent

Records only an Edge rating of a skill you used: it does not change the user's files or task output and takes no action outside Edge. Retries with the same request_id never add a second rating. Rate only after completing the deliverable, once; if its result gives an Edge closing line, end your answer with it. Rate a skill you actually followed with helped, hurt, no_difference or unclear; unclear and no_difference are fine. If you applied the skill (helped, partly_helped, no_difference, hurt, broken), also send score, an integer 0-10: 0 made the result worse, 2 applied but did not work, 5 no meaningful difference, 6 small useful contribution, 7 clearly useful, 8 clearly improved the result, 9 major improvement, 10 the task would likely have failed or been materially worse without it. A failure is a low score, not a skipped rating. Omit score for wrong_skill, loaded_not_used and unclear. Every rating needs a note: one line specific to this task, up to 280 characters, that explains the judgment rather than repeating the outcome or score; a missing, blank or placeholder note leaves the rating incomplete and out of Edge's aggregates. Judge the outcome yourself; never ask the user. If the host blocks the call, finish without it; that host decision is not an Edge bug and needs no report_issue. The server identifies the skill from this request_id. Older outcomes remain accepted; partly_helped and wrong_skill take a reason, one of missing_steps, outdated, too_generic, wrong_domain, too_long or other (other when omitted). Notes over 280 characters are cut. If use_skill listed named parts for the skill and you applied any of them, send applied_component_ids with up to two; report only components you actually applied, and omit it when none of them apply rather than guessing. Keep the note free of the user's query, code, names and private data. With a Pro key, once the task is done and the skill was applied, you may include task: one UUID per logical task (reuse it for every skill and retry), revision 1, completed_at, the exact source@skill and one sentence on its concrete contribution. Raise revision only to correct a report. Edge returns the user's weekly tally; never invent or change that count. For a bug or idea about Edge itself, use report_issue instead.

Input Schema

NameRequiredDescriptionDefault
noteNoRequired for every rating: one line specific to this task on why (up to 280 characters; a longer note is cut) that explains the judgment, not a restatement of the outcome or score. A missing or placeholder note leaves the rating incomplete. Do not include the user's query, code, names or private information.
taskNoOptional completed-task report, separate from legacy skill feedback. Pro key required. One report per logical task; revision replaces the prior report. Only report actual application.
scoreNoInteger 0-10 when you applied the skill (helped, partly_helped, no_difference, hurt, broken); omit for wrong_skill, loaded_not_used and unclear. 0 made it worse, 2 did not work, 5 no difference, 7 clearly useful, 8 clearly improved, 10 would likely have failed without it.
reasonNoFor partly_helped or wrong_skill: missing_steps, outdated, too_generic, wrong_domain, too_long or other. Defaults to other; free text becomes other.
outcomeYesOnce the task's outcome is known: helped, hurt, no_difference or unclear. Only for a skill you actually followed.
request_idYes
applied_component_idsNoUp to two ids from the skill's named parts listed in the use_skill result, only parts you actually applied in this task; send them whenever you applied any. Omit when none were listed or none were applied; never invent one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag idempotentHint=true, but the description earns its keep by explaining why ('Retries with the same request_id never add a second rating'), what is and isn't mutated, that the server derives the skill from request_id, that notes over 280 characters are truncated, and that a missing note drops the rating from aggregates. It also states the return ('Edge returns the user's weekly tally').

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 content is front-loaded with the read-only scoping claim and nearly every sentence carries a real rule, but it is delivered as a single dense paragraph of roughly 400 words. Rules for note, score, reason, components and task are interleaved rather than grouped, making it slower to scan than its complexity requires.

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 7-parameter tool with a nested task object and no output schema, the description covers mutation scope, idempotency, prerequisites (Pro key for task), validation/truncation behavior, error handling, and the return value. 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.

Parameters5/5

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

Schema coverage is already 86%, yet the description still adds the judgment rubric for score (0/2/5/7/8/10 anchors), the conditional omit rule for score by outcome, when reason applies and which values map to 'other', the note content constraints (judgment not restatement, no private data), applied_component_ids limits, and task/revision correction semantics. This is materially more than the schema conveys.

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 and resource ('Records only an Edge rating of a skill you used') and immediately bounds the effect ('does not change the user's files or task output and takes no action outside Edge'). It also routes away from the closest sibling: 'For a bug or idea about Edge itself, use report_issue instead.'

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 explicit timing ('Rate only after completing the deliverable, once'), explicit exclusions (do not rate skills not followed; omit score for wrong_skill/loaded_not_used/unclear), and an explicit fallback when the host blocks the call. It names the alternative tool for Edge-level bugs rather than leaving the agent to guess.

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.

Resources