Skip to main content
Glama
Sign In
patchbay

patchbay

by GodSmasher
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Verify a connector

verify_code

Type-check and test TypeScript or Python connector files in an isolated Nebius sandbox, retry repairs, and return the final test report with updated files.

Instructions

Type-check and test an existing connector (files you provide as {path, content}) in an isolated Nebius sandbox, with up to N repair attempts from the strong model. For TypeScript (default) the gate is tsc + vitest; for Python (lang: "py") it is compileall + pytest. Requires live keys (NEBIUS_API_KEY, NEBIUS_AI_PROJECT); returns the final test report and the (possibly repaired) files.

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": {
      "files": "<files>"
    },
    "name": "verify_code"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoTarget language the files are in. "ts" (default) or "py". If omitted, auto-detected from file extensions.
filesYesConnector files. For TS, include src/connector.ts + a *.test.ts; for Python, include connector.py + test_connector.py.
maxAttemptsNoRepair attempts, default from PATCHBAY_MAX_ATTEMPTS

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/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 behavioral burden and does well: it discloses the isolated sandbox, repair-attempt behavior, required live environment variables, language-specific test gates, and that the result includes a test report plus possibly repaired files. It does not describe failure behavior when tests still fail or whether the repair attempts modify the caller's original files.

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 dense paragraph that front-loads the core action and then adds relevant constraints. There is little wasted wording, though the density makes it slightly harder to scan than a more structured definition. Every clause contributes useful 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?

There is no output schema, so the description appropriately explains that the tool returns the final test report and possibly repaired files. It also covers authentication requirements, isolation, and language-specific verification behavior. Missing details about failure handling and whether repair attempts affect caller-provided files are minor gaps rather than major omissions.

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 already 100%, documenting lang, files, and maxAttempts. The description adds useful context about the test gates and that files are provided as {path, content}, but it does not add format details or constraints beyond what the schema already provides. Baseline 3 is appropriate when the schema does the parameter-level work.

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: type-check and test an existing connector in an isolated Nebius sandbox. It also clarifies the language-specific gates (tsc + vitest for TS, compileall + pytest for Python), which makes the purpose concrete. It does not explicitly name or contrast with build_connector or audit_mcp_server, so sibling differentiation is only implicit via 'existing connector.'

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?

Usage is implied by 'existing connector' and the verification gates, suggesting this is for validating files after they already exist. However, there is no explicit when-to-use versus when-not-to-use guidance and no named alternative such as build_connector for creating connectors. An agent can infer the context but is not routed decisively.

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