Skip to main content
Glama
Sign In
SapperMCP

SapperMCP

by MasterX1582
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sapper Frontier

sapper_frontier

List open intents ready to work, showing dependency-met and confirmed items first with claimed intents prioritized, so agents can select actionable tasks.

Instructions

List open intents that are ready to work (dependencies met, confirmed). Claimed intents come first.

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": "sapper_frontier"
  }
}

Input Schema

NameRequiredDescriptionDefault
storeNo.sapper

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are present, so the description carries the full burden; it does disclose the inclusion filter (dependencies met, confirmed) and the result ordering ('Claimed intents come first'), which is genuine behavioral context. It stops short of stating that this is a non-mutating read, any pagination or result-size behavior, or scope limits.

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?

Two short sentences, zero filler, with the selection criteria and the ordering front-loaded. Nothing could be removed without losing information.

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?

An output schema exists, so return values need no explanation, and the tool is simple (one optional parameter). The only meaningful omission is the purpose and format of the 'store' parameter, which leaves a small but real gap for such a minimal tool.

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

Parameters2/5

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

The single parameter 'store' has 0% schema description coverage, so the description is the only place its meaning could be supplied — and it never mentions the parameter at all. An agent must guess that '.sapper' is a filesystem path to a state directory and how that affects the listing.

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?

States a specific verb and resource ('List open intents') plus the qualifying condition ('ready to work – dependencies met, confirmed'), so an agent knows exactly what set is returned. It does not explicitly differentiate itself from sibling listing tools such as sapper_board or sapper_status, which keeps it short of a 5.

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

Usage Guidelines3/5

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

The phrase 'ready to work' implicitly signals this is the queue to pull from, but the description never says when to prefer it over siblings or what the follow-up action is (e.g. claiming via sapper_claim). Usage is inferable rather than stated.

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

Deploy Server

Other Tools