FlagForge MCP Server

update_challenge

Modify an existing CTF challenge's fields such as title, description, points, tags, category, and connection info using its unique challenge ID.

Instructions

Update an existing challenge's fields (title, description, points, tags...)

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": {
      "challenge_id": "<challenge_id>"
    },
    "name": "update_challenge"
  }
}

Input Schema

Name	Required	Description	Default
`tags`	No
`title`	No
`points`	No
`category`	No
`challenge_id`	Yes
`connection_info`	No
`description_markdown`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 5, 2026

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It only states that the tool updates fields, which is essentially the core operation; it does not disclose whether updates are partial or full replacement, how omitted fields are treated, what happens on invalid input, or whether permissions are required. No contradiction with annotations exists, but the behavioral detail is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. The verb 'Update' and the resource 'existing challenge's fields' appear first, making the core purpose immediately clear. It is concise, though the ellipsis placeholder is a minor structural weakness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters, no output schema, and no annotations, this description is incomplete. It does not explain partial-update behavior, which fields are optional, whether a full replacement occurs, or how the update interacts with sibling status/claim tools. An agent would need to inspect the schema and infer several important behaviors to safely invoke the 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?

Schema description coverage is 0%, so the description must compensate, but it only names a few fields (title, description, points, tags) and relies on '...' for the rest. It does not explain that challenge_id is the required identifier, that other fields are optional, or how the update semantics apply to each parameter. This adds little beyond the schema's property names.

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?

The description clearly identifies the operation as updating an existing challenge's fields, with concrete examples (title, description, points, tags). This distinguishes it from create/delete/get/list sibling tools. However, it leaves the scope slightly open with '...' and does not clarify whether status updates are included or excluded, especially given the separate set_challenge_status sibling.

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 description implies usage: use this when you need to modify fields on an existing challenge. It does not explicitly state when not to use it or mention alternatives like create_challenge or set_challenge_status, so the agent must infer the boundary. This is adequate but lacks direct routing guidance.

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