Skip to main content
Glama

shelve

Temporarily hide a GitHub pull request from daily checks and status reports while keeping it tracked in the system.

Instructions

Shelve a PR to temporarily hide it from daily checks and status reports without untracking it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prUrlYesFull GitHub PR URL to shelve

Implementation Reference

  • The 'shelve' tool is registered in packages/mcp-server/src/tools.ts. It delegates its execution to `runMove` with the 'shelved' target.
    // 16. shelve — Shelve a PR
    server.registerTool(
      'shelve',
      {
        description: 'Shelve a PR to temporarily hide it from daily checks and status reports without untracking it.',
        inputSchema: {
          prUrl: z.string().describe('Full GitHub PR URL to shelve'),
        },
        annotations: { readOnlyHint: false, destructiveHint: false },
      },
      wrapTool((args: { prUrl: string }) => runMove({ prUrl: args.prUrl, target: 'shelved' })),
    );
  • The core logic for shelving a PR is implemented in `runMove` within packages/core/src/commands/move.ts, which updates the state via `stateManager`.
    case 'shelved': {
      stateManager.batch(() => {
        stateManager.shelvePR(options.prUrl);
        stateManager.clearStatusOverride(options.prUrl);
      });
      return {
        url: options.prUrl,
        target,
        description: 'Shelved — excluded from capacity and actionable items',
      };
    }
Behavior4/5

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

Annotations indicate this is a non-destructive write operation (readOnly: false, destructive: false). The description adds valuable specific behavioral context: the PR is hidden from 'daily checks and status reports' but remains tracked. This domain-specific consequence goes beyond the generic annotation flags.

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?

Single sentence with zero waste. It front-loads the action, explains the effect, and concludes with the crucial distinction from untracking. Every phrase earns its place by conveying distinct information about behavior, scope, or sibling differentiation.

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?

For a single-parameter state-change tool with no output schema, the description is nearly complete. It covers the action, the side effects, the temporary nature (implying reversibility via the 'unshelve' sibling), and distinguishes from 'untrack'. One point deducted only because it could explicitly mention that 'unshelve' reverses this action, though this is inferable.

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?

With 100% schema description coverage (prUrl is fully documented as 'Full GitHub PR URL to shelve'), the baseline score is 3. The description implies the PR target but doesn't add parameter-specific semantics (e.g., format requirements, validation rules) beyond what the schema already provides.

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 uses a specific verb ('Shelve') with a clear resource ('PR') and explains the exact effect ('temporarily hide it from daily checks and status reports'). It explicitly distinguishes this from the 'untrack' sibling by stating 'without untracking it', immediately clarifying the temporary vs. permanent distinction.

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

Usage Guidelines4/5

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

The description provides clear context about when to use this tool—when you want to temporarily suppress a PR from reports without stopping tracking entirely. The phrase 'without untracking' implicitly positions this against the 'untrack' sibling, though it doesn't explicitly name alternatives or provide explicit 'when-not-to-use' guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/costajohnt/oss-autopilot'

If you have feedback or need assistance with the MCP directory API, please join our Discord server