Skip to main content
Glama
Sign In

Codequiry

by com.codequiry
OverviewDiscussionsAdmin

Read the other side of a match

codequiry_get_match_counterpart
Read-onlyIdempotent

Return the code a match was found against, with the line ranges on both sides: the peer submission's file for a peer match, or the cached copy of the external page for a web match. match_id is the id of an entry in matches or web_files from view_submission. Pass legacy true when that entry is flagged is_legacy_web. AI matches have no counterpart.

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": {
      "check_id": "<check_id>",
      "submission_id": "<submission_id>",
      "match_id": "<match_id>"
    },
    "name": "codequiry_get_match_counterpart"
  }
}

Input Schema

NameRequiredDescriptionDefault
legacyNotrue when the entry is flagged is_legacy_web.
check_idYesThe check id returned when the check was created.
match_idYesThe id of an entry in matches or web_files from view_submission.
submission_idYesSubmission id, from get_check, get_overview or view_submission.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. Beyond that, the description discloses the payload shape (code plus line ranges on both sides) and the branching behavior driven by match type and the legacy flag, which are real behavioral facts not in the annotations. Return formatting details beyond "line ranges" remain unspecified.

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?

Two sentences, both front-loaded: the return contract first, then the identifier/flag rules. Every clause carries information — the peer/web split, the source tool for ids, and the legacy condition — with no filler.

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?

There is no output schema, so the description must explain returns, and it does so at a useful level (code plus line ranges on both sides, per match type). For a four-parameter read tool whose annotations cover the safety profile, this is close to complete; only finer return details (e.g., how line ranges are represented, error behavior for AI matches) are absent.

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 description coverage is 100% and the description's parameter guidance (match_id provenance, legacy trigger) largely restates the schema property descriptions verbatim. It confirms the cross-tool provenance chain (view_submission) but adds no new syntax, format, or constraint beyond the schema. Baseline 3 applies when the schema carries the parameter documentation.

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 concrete verb and resource ("Return the code a match was found against") and enumerates the two result variants: the peer submission's file for peer matches and the cached external page for web matches. It does not differentiate itself from the sibling codequiry_get_matched_web_source, which sounds like it also surfaces web-side material, so an agent may hesitate between the two.

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?

It tells the agent where match_id comes from (an entry in matches or web_files from view_submission), the conditional trigger for legacy=true (is_legacy_web flagged), and a clear when-not case ("AI matches have no counterpart"). It stops short of naming a sibling alternative for the web case, but the usage conditions are otherwise explicit.

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

All Codequiry toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources