Skip to main content
Glama
Sign In
mtg-forja

mtg-forja

by grutino
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

listar_reglas

Lists known card interaction patterns with IDs and the specific synergies or conflicts they identify in a Magic: The Gathering deck.

Instructions

Lista los patrones de interacción que conoce el motor, con su id y qué buscan.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "listar_reglas"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It implicitly indicates a read-only listing operation and discloses the return fields (id and what patterns look for), but it does not explicitly state side effects, pagination, or any prerequisites. For a simple list tool, this is adequate but not rich.

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?

The description is a single, well-structured sentence that is front-loaded with the action verb and resource. No unnecessary words or repetition.

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 simple zero-parameter listing tool with an output schema, the description covers the essential behavior and return content. It lacks deeper context such as when to use it or what 'patrones de interacción' implies, but given the low complexity, it is sufficiently complete.

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?

The tool has zero parameters, so there is nothing to explain. The schema coverage is 100% and the description adds no parameter-related information, which is acceptable. Baseline for 0-param tools is 4.

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 uses a specific verb ('Lista') and identifies the resource ('patrones de interacción que conoce el motor'), and specifies the output contents ('con su id y qué buscan'). It is clear and distinct from the sibling tools, though it does not explicitly contrast with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the sibling tools. The description only states what the tool does, not in which context it should be preferred over alternatives like combos_conocidos or detectar_sinergias.

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

Deploy Server

Other Tools