Skip to main content
Glama
Sign In

md-doc

by com.md-doc.app
OverviewDiscussionsAdmin

vs_play

Tu jugada en una partida del MODO VS; solo en tu turno. move propose: arguments (qué discutes de la solución del rival) + solution (tu solución completa). accept: la última solución del rival vale tal cual (arguments opcional): termina con acuerdo. close: sin acuerdo, solution (tu solución final) + arguments (por qué la del rival no es correcta). Después, llama a vs_wait.

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": {
      "matchId": "<matchId>",
      "seatToken": "<seatToken>",
      "move": "<move>"
    },
    "name": "vs_play"
  }
}

Input Schema

NameRequiredDescriptionDefault
moveYespropose | accept | close
matchIdYesID de la partida
summaryNoUNA línea (máx. 200 caracteres) que resuma tu jugada; obligatoria salvo en accept. La ve el usuario en el marcador
solutionNoTu solución completa (propose, close)
argumentsNoTus argumentos sobre la solución del rival
seatTokenYesTu seatToken (te lo dio vs_open o vs_join): identifica tu puesto en la partida

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose the consequence of each move (accept terminates with agreement, close terminates without agreement) plus the turn constraint. It still leaves gaps: nothing about what happens if it is not your turn, whether the match ends on close, or what the tool returns.

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?

It is front-loaded with the action and the turn constraint, then enumerates the three moves in a compact semicolon structure with no filler. The run-on phrasing and inline parentheticals are dense but each clause adds operational information.

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 six-parameter, no-output-schema gameplay tool it covers the essentials: turn precondition, per-move payloads, and the follow-up call. The main omission is the required summary field, which the schema enforces but the description never mentions, so an agent reading only the description would not know to supply it.

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 adds real meaning by mapping parameters to moves (arguments+solution for propose, optional arguments for accept, solution+arguments for close), which the schema does not state. It omits any mention of the summary parameter, which the schema marks as required except on accept.

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 states a specific action ("Tu jugada") bound to a specific context ("una partida del MODO VS") and a precondition ("solo en tu turno"). It also explicitly names the sibling it hands off to ("vs_wait"), so an agent can tell this apart from vs_wait/vs_get without opening the schema.

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 gives an explicit when-to-use condition (only on your turn) and a when-to-call-next rule ("Después, llama a vs_wait"). It further routes between the three move variants by describing the outcome that selects each: propose to contest, accept to agree, close to end without agreement.

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

All md-doc toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources