FlagForge MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FLAGFORGE_TOKEN | Yes | Bearer token of the agent (created from admin → Agents). Must be an agent principal token (role: reader/solver/submitter/admin) or an admin bootstrap token. Permissions are enforced according to the token's role. | |
| FLAGFORGE_BASE_URL | Yes | The base URL of the FlagForge web app. For example, http://localhost:3000 |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_eventsA | List CTF events with challenge/solved counts |
| create_eventA | Create a new CTF event (requires admin role) |
| list_challengesC | List challenges in an event (by event id or slug) |
| get_challengeA | Get one challenge's summary: description, status, tags, flag status, lock owner |
| create_challengeA | Create (write) a new challenge in an event — for manual entry, mockups, or archiving self-made challenges |
| update_challengeC | Update an existing challenge's fields (title, description, points, tags...) |
| delete_challengeA | Delete a challenge and its evidence/flags/artifacts (admin only, cascades) |
| claim_challengeA | Lock a challenge to this agent (15-min lease; 409 if someone else holds it) |
| release_challengeB | Release the claim/lock on a challenge |
| set_challenge_statusC | Update working status: unopened | triaging | in_progress | blocked | solved | verified | failed |
| list_evidenceC | List evidence recorded on a challenge |
| save_evidenceA | Record evidence during solving (hypothesis, observation, command output...) |
| list_flagsA | List flags on a challenge (redacted previews only — the vault never returns plaintext) |
| submit_flag_candidateB | Store a flag candidate for a challenge (encrypted at rest, deduplicated) |
| get_writeupA | Read a challenge's writeup (Thai human + English AI) |
| save_writeupA | Save a writeup as markdown. Record Thai for human review, English for AI-generated. Markdown is rendered on the challenge page — headings, code blocks, tables and images all display. To embed an image:
External image URLs (https://...) also render. Do NOT use relative paths like /_astro/... — they will 404 on the FlagForge site. |
| search_knowledgeA | Search across all events: challenge descriptions, writeups (Thai/English), tags — find how similar challenges were solved before |
| list_artifactsB | List files/artifacts attached to a challenge (images, pcaps, notes) with sha256 |
| upload_artifactA | Upload a file (screenshot, pcap, note) to a challenge as an artifact. Provide either a local file path (read from disk) or raw content bytes
with a filename. Returns the artifact record — use its id to embed images
in writeups: |
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 19 tools
Every tool targets a specific resource and action pair: events, challenges, evidence, flags, writeups, artifacts, and knowledge search. The only possible near-overlap between update_challenge and set_challenge_status is resolved by the latter being explicitly scoped to lifecycle status.
Tool names follow a consistent lowercase snake_case verb_noun pattern throughout, such as list_*, create_*, get_*, update_*, delete_*, save_*, and upload_*. This makes the intended action of each tool predictable and easy to select.
At 19 tools, the set is slightly above the typical well-scoped range, but the breadth is justified by the full CTF workflow: events, challenge CRUD, status/locking, evidence, flags, writeups, artifacts, and search. No tools are redundant; each contributes a distinct operation.
The core challenge lifecycle is well covered with create/read/update/delete plus status, locking, evidence, flags, writeups, and artifacts. Minor gaps exist around event updates/deletes and direct artifact retrieval, but agents can work around these for solving and documentation workflows.