Scepter
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | Set GITHUB_TOKEN in your environment to raise the GitHub API rate limit. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_serverA | Check whether one MCP server is alive, maintained, and safe to use, from its npm package or GitHub repo. Returns a 0-100 score, a verdict (healthy, caution, risky), and the signals behind it. |
| scan_configA | Run check_server on every npm-launched MCP server listed in an MCP config file (for example mcp.json). |
| inspect_serverA | Start an MCP server (stdio command, or a Streamable HTTP url), read its tool list, and audit it: poisoned tool descriptions, destructive tools without a destructiveHint, context cost in tokens, and tools that changed since the last inspection. |
| audit_configA | Start every server in an MCP config file, audit each one like inspect_server, and report toxic flows: combinations of tools that read untrusted content, read private data, and send data out. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
audit_config, check_server, and scan_config overlap somewhat: audit_config and scan_config both operate on config files and spawn servers, but audit_config focuses on toxic flows while scan_config runs check_server. check_server and inspect_server are fairly distinct (npm/repo health vs. live server tool-list audit) but both 'audit' a server, which could cause some confusion.
Two patterns coexist: <verb>_config (audit_config, scan_config) and <verb>_server (check_server, inspect_server). Within groups it's consistent, but the mix of _config and _server targets alongside two different verbs for auditing makes the scheme only partially predictable.
Four tools for a focused audit/scanning domain is lean but reasonable, each earning a place. It sits at the lower boundary of well-scoped rather than heavy.
Core flows—inspecting a single server, checking a package/repo, scanning and auditing a config—are covered. However there's no way to get/review prior inspection reports individually, diff drift over time, or audit a URL-based config comprehensively, leaving some lifecycle gaps.