Skip to main content
Glama
Sign In
yof

yof

Official
by yof-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Patch pull requests

yof_patch_status
Read-onlyIdempotent

List Patch’s open fix pull requests and their CI check states, optionally for one app, to see whether each proposed fix is waiting, passing, or failing.

Instructions

List Patch's open fix pull requests from your yof.io account, with the state of each one's CI checks. Use it to see whether a fix Patch proposed is waiting, passing or failing; use yof_lessons for fixes already merged, and yof_findings for problems with no pull request yet. Needs YOF_API_KEY; sends only app_id to yof.io, which answers from what it last stored (up to 50, newest first) without asking GitHub again. Returns open (repository, number, url, draft, rule, title, checks, failed_checks, opened) and a note; an empty list means Patch has no open pull request.

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": "yof_patch_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
app_idNoOne app's id, to list only that app's pull requests. Default: every app in the account.

Output Schema

NameRequiredDescriptionDefault
noteNoReminder that this tool changes nothing.
openYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.2
    • changedInput schema / properties / app_id / description
      Previous value: -"One app's id (default: all)."New value: +"One app's id, to list only that app's pull requests. Default: every app in the account."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "note": {
+      "description": "Reminder that this tool changes nothing.",
+      "type": "string"
+    },
+    "open": {
+      "items": {
+        "properties": {
+          "checks": {
+            "description": "CI state as yof last stored it.",
+            "type": "string"
+          },
+          "draft": {
+            "type": "boolean"
+          },
+          "failed_checks": {
+            "description": "Names of failed checks, at most 20.",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "number": {
+            "description": "Pull request number.",
+            "type": "integer"
+          },
+          "opened": {
+            "description": "ISO time.",
+            "type": "string"
+          },
+          "repository": {
+            "description": "owner/name on GitHub.",
+            "type": "string"
+          },
+          "rule": {
+            "description": "The rule the fix is for.",
+            "type": "string"
+          },
+          "title": {
+            "description": "Readable rule name.",
+            "type": "string"
+          },
+          "url": {
+            "description": "Pull request URL.",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "open"
+  ],
+  "type": "object"
+}
  2. First observedv0.3.1

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (which already mark this read-only, idempotent, non-destructive and open-world), it discloses that YOF_API_KEY is required, that only app_id leaves the client, and that results come from yof.io's last stored snapshot rather than a fresh GitHub call, capped at 50 newest-first. That staleness and data-egress context is exactly what annotations cannot convey.

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?

Front-loaded with the core action, then routing guidance, then operational constraints, then return shape — a sensible order with no filler. It is dense and the return-field enumeration partly duplicates the output schema, which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers everything an agent needs: what it lists, when to prefer it, auth requirement, data-flow limits, freshness/50-item cap, the returned fields, and the meaning of an empty list. Nothing material is missing for a one-parameter read tool.

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 single app_id parameter is fully documented there, including its default, so the schema does the heavy lifting. The description only reinforces that app_id is the sole payload sent to yof.io, which is useful but marginal 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?

States a specific verb and resource: 'List Patch's open fix pull requests from your yof.io account, with the state of each one's CI checks.' It also implicitly distinguishes itself from the other read tools by naming what it is not (yof_lessons for merged fixes, yof_findings for problems without a PR).

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?

Gives an explicit decision rule: use this to see whether a proposed fix is waiting, passing or failing; use yof_lessons for already-merged fixes; use yof_findings for problems with no PR. The alternatives and the conditions that select them are both spelled out.

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