Skip to main content
Glama
Sign In
BunkerWeb MCP

BunkerWeb MCP

Official
by bunkerity
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_service

Read-only

Retrieve a BunkerWeb service’s settings by ID and see which method set each value. Optionally include defaults or hide drafts to inspect its configuration.

Instructions

Read one service's settings by ID (its first SERVER_NAME), with the method that set each; full=true adds defaults, with_drafts=false hides drafts. 404 if unknown. Cached up to 5 min. Use list_services to find IDs, get_global_config for global ones.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "service": "<service>"
    },
    "name": "get_service"
  }
}

Input Schema

NameRequiredDescriptionDefault
fullNoInclude derived defaults
methodsNoInclude method metadata
serviceYesService ID (its first SERVER_NAME), as list_services returns it
with_draftsNoInclude draft services

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.0
    • changedInput schema / properties / service / description
      Previous value: -"Service identifier"New value: +"Service ID (its first SERVER_NAME), as list_services returns it"
  2. Changed4 schema fields changedv0.5.0
    • addedInput schema / properties / full / description
      Added value: +"Include derived defaults"
    • addedInput schema / properties / methods / description
      Added value: +"Include method metadata"
    • addedInput schema / properties / service / description
      Added value: +"Service identifier"
    • addedInput schema / properties / with_drafts / description
      Added value: +"Include draft services"
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnlyHint=true, it discloses error behavior ('404 if unknown') and a caching window ('Cached up to 5 min'), which tells the agent results may be stale after a write – context no annotation provides. It also spells out the effect of each flag ('full=true adds defaults, with_drafts=false hides drafts'), so the read is fully characterized.

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 dense sentences, front-loaded with the core operation before flags, failure mode, caching, and the alternative-tool routing. No filler; each clause carries information an agent needs to call it correctly.

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 read-only, single-entity fetch with four fully documented parameters and no output schema, the description covers selection, flags, failure, staleness, and alternatives. The only mild gap is that the shape of the returned settings is only broadly implied ('settings ... with the method that set each'), though that is adequate for a read tool.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description still adds meaning: it clarifies that 'service' is the first SERVER_NAME as list_services returns it and that method metadata accompanies each setting (the 'methods' parameter, whose schema text is only 'Include method metadata'). The full/with_drafts explanations largely restate their schema defaults, so it is a modest gain over structured data rather than a transformative one.

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 gives a precise verb and resource ('Read one service's settings by ID') and specifies the exact identifier form ('its first SERVER_NAME'), plus what is included ('with the method that set each'). It is immediately distinguishable from list_services (enumeration) and get_global_config (global-scope settings).

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?

It explicitly routes the agent: 'Use list_services to find IDs, get_global_config for global ones.' Both the precondition for use and the sibling alternative for the adjacent case are named, leaving little to inference.

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