Repovive MCP Server

Attach draft to a contest

repovive_build_add_to_contest

Attach a verified draft to a contest as a real problem, publishing it only with explicit user approval.

Instructions

Publish a draft by attaching it to a contest as a real problem. This is the step that makes authored work visible on the platform — never call it without the user's explicit approval. Verify the draft builds cleanly first.

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": {
      "session_id": "<session_id>",
      "body_json": "<body_json>"
    },
    "name": "repovive_build_add_to_contest"
  }
}

Input Schema

Name	Required	Description	Default
`body_json`	Yes	JSON body for add-to-contest, e.g. {"contestId": "<24-hex>"}
`session_id`	Yes	Build session id

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 1, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already signal readOnlyHint=false and idempotentHint=false, so the non-read-only nature is covered. The description adds meaningful behavioral context by stating that this action makes authored work visible on the platform and that explicit user approval is required — information not available from annotations alone.

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?

Three sentences with no wasted words. The primary purpose is front-loaded in the first sentence, and the critical prerequisite and consent requirement follow efficiently without redundancy.

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

Completeness5/5

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

Given the rich schema (100% parameter coverage), existing output schema, and annotations covering read-only/idempotent/destructive behavior, the description is complete for correct invocation. It adds the crucial preconditions and visibility consequence that are not encoded elsewhere.

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?

Schema coverage is 100%, so the parameters are fully documented in the schema. The description mentions 'draft' and 'contest' conceptually but does not add any detail about session_id or body_json beyond what the schema already provides; the baseline of 3 is appropriate.

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 states a specific verb and resource: 'Publish a draft by attaching it to a contest as a real problem,' which clearly identifies the operation and its role. However, it does not explicitly distinguish itself from adjacent sibling tools like build_push_problem or build_author_complete_problem, so the differentiation is implicit rather than explicit.

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 execution context: verify the draft builds cleanly first, and never call without explicit user approval. This tells the agent when it is appropriate to invoke the tool, though it does not name alternative tools or say when not to use it.

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

Deploy Server