Skip to main content
Glama
Sign In
patchbay

patchbay

by GodSmasher
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Build a connector

build_connector

Generate a tested, documented connector between two APIs from a one-sentence integration description. Plans, researches both APIs, writes tests and a README, then verifies in a sandbox with repair attempts.

Instructions

Describe an integration in one sentence ("When X happens in A, do Y in B"). patchbay plans it, researches both APIs, generates a connector with tests and a README, then verifies it in a sandbox with up to N repair attempts. Default language is TypeScript (vitest); set lang: "py" for Python 3.12 (pytest). Falls back to the recorded TypeScript replay run when live API keys are missing.

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": {
      "prompt": "<prompt>"
    },
    "name": "build_connector"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoTarget language. "ts" (default) emits TypeScript+vitest; "py" emits Python 3.12+pytest. Live keys required for "py".
promptYesOne-sentence integration description
maxAttemptsNoRepair attempts, default from PATCHBAY_MAX_ATTEMPTS

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full behavioral burden and does substantial work: it discloses the multi-stage pipeline, bounded repair attempts, the sandbox verification step, and a fallback to a recorded TypeScript replay when live API keys are absent. It omits latency/cost expectations and where generated artifacts land, which matters for a long multi-step generation tool.

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 core instruction and input format are front-loaded in the first sentence, followed by pipeline behavior, language selection, and fallback in a compact four-sentence block. Every sentence contributes a fact the agent would otherwise have to guess.

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 complex multi-stage generator with no output schema, the description conveys what gets produced (connector, tests, README, sandbox verification) and the failure mode. It could go further by describing the return payload or artifact locations, but nothing essential to correct invocation is missing.

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%, so lang, prompt, and maxAttempts are already documented, and the description largely restates the TypeScript default and py option. The one genuine addition is the prompt pattern example ('When X happens in A, do Y in B'), which helps the agent formulate valid input, but the other parameters gain no meaning beyond the schema.

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 verb-plus-resource ('generates a connector') and enumerates the internal pipeline: plan, research both APIs, generate code with tests and README, verify in sandbox. Because it names the research and verification steps as internal, an agent can tell it apart from siblings like research_api and verify_code without opening a schema.

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 gives clear context for invocation by prescribing the input shape ('Describe an integration in one sentence') and explaining the lang switch and the missing-key fallback. It stops short of explicit exclusions — it never says to call research_api or verify_code instead when only a single step is wanted.

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