Skip to main content
Glama

check_skill_run

Reserve ONE run of a LemMeBuyIt skill against your plan's daily limit. Call this exactly once at the start of a skill. If allowed is false, stop and tell the user the plan_notice message (the daily limit was reached); do not continue the skill.

Input Schema

NameRequiredDescriptionDefault
skill_idYesThe skill id, e.g. "resale-arbitrage-scan".
capabilityNoOptional capability slice for usage analytics: one of deal|resale|coupon|watch|full.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already flag this as non-read-only and non-idempotent; the description adds real context on top of that by naming the consumed resource (daily quota), the exact-once calling contract, and the output fields `allowed` and `plan_notice` even though no output schema exists. It does not say whether a reserved run is refunded if the skill aborts, which is the one behavioral gap.

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

Conciseness5/5

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

Three sentences, zero waste, and the critical constraint (reserve ONE run, once) is front-loaded before the conditional failure handling. Every sentence carries a distinct actionable instruction.

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 quota-gating call with no output schema, the description supplies the missing return semantics (allowed, plan_notice) and the required agent behavior on denial. An agent has everything needed to invoke and act on the result 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 100%, so `skill_id` and `capability` (including its deal|resale|coupon|watch|full slice) are already documented in the schema. The description's phrase "a LemMeBuyIt skill" adds only marginal framing and repeats no parameter syntax, so baseline 3 applies.

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 (reserve) and resource (one run of a LemMeBuyIt skill) plus the scoping constraint (against the plan's daily limit). Nothing in the sibling list does anything similar, so an agent can immediately tell this apart from pricing/history/listing tools.

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 call timing ("exactly once at the start of a skill") and an explicit branch on the result ("If allowed is false, stop and tell the user the plan_notice message ... do not continue the skill"). Both the when-to-use and the failure path are spelled out rather than inferred.

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