yof

Official

by yof-dev

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Check the project

yof_check

Read-onlyIdempotent

Scan a project or subfolder for leaked API keys and made-up, lookalike, or vulnerable packages before finishing work, with optional offline mode and redacted findings.

Instructions

Scan the project folder on this computer (or one folder inside it) for leaked API keys and for made-up, brand-new, lookalike or vulnerable packages. Use it for a full pass, for example before you say the work is done; after small edits use yof_check_diff, which reads only the changed lines. Files are read locally and never uploaded; only package names and versions go to npm, PyPI and OSV, unless offline is true. It follows .yof.yml and .gitignore, reads at most 20,000 files (stopped_early says so), looks up at most 500 dependencies and gives up after 90 seconds. Returns counts, must_fix_before_done and up to 100 findings with secrets redacted; an empty list means nothing was found within those limits.

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_check"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No	A folder inside the project, relative to the project root, for example "src". Default: the whole project. Paths outside the project are refused.
`offline`	No	true skips the npm, PyPI and OSV lookups, so nothing leaves this computer; package problems are then not reported. Default false.

Output Schema

Name	Required	Description
`more`	No	How many findings were left out of the list, when there are more than 100.
`next`	Yes	What to do next.
`counts`	Yes	How many findings of each urgency (all of them, not only the listed ones).
`profile`	Yes	The .yof.yml profile that decided which urgencies are shown.
`project`	Yes	The folder scanned, relative to the project root.
`findings`	Yes	At most 100 findings. kind is key or package; value is a prefix plus REDACTED.
`files_scanned`	Yes	How many files were read.
`stopped_early`	Yes	true when the file limit was reached before every file was read.
`package_lookups`	Yes	"off", or which registries were asked (names and versions only).
`dependencies_checked`	Yes	How many dependencies were looked up.
`must_fix_before_done`	Yes	true when at least one fix_now finding is open.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.3.2Nov 10, 2026

changedInput schema / properties / offline / description

Previous value: -"Skip the package-registry lookups (no network at all). Default false."New value: +"true skips the npm, PyPI and OSV lookups, so nothing leaves this computer; package problems are then not reported. Default false."

changedInput schema / properties / path / description

Previous value: -"A folder inside the project, relative to its root (default: the whole project)."New value: +"A folder inside the project, relative to the project root, for example \"src\". Default: the whole project. Paths outside the project are refused."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "counts": {
+      "description": "How many findings of each urgency (all of them, not only the listed ones).",
+      "properties": {
+        "fix_now": {
+          "type": "integer"
+        },
+        "fix_week": {
+          "type": "integer"
+        },
+        "info": {
+          "type": "integer"
+        }
+      },
+      "type": "object"
+    },
+    "dependencies_checked": {
+      "description": "How many dependencies were looked up.",
+      "type": "integer"
+    },
+    "files_scanned": {
+      "description": "How many files were read.",
+      "type": "integer"
+    },
+    "findings": {
+      "description": "At most 100 findings. kind is key or package; value is a prefix plus REDACTED.",
+      "items": {
+        "properties": {
+          "file": {
+            "description": "Path relative to the project root.",
+            "type": "string"
+          },
+          "kind": {
+            "description": "key or package.",
+            "type": "string"
+          },
+          "line": {
+            "description": "Line in the file (key findings).",
+            "type": "integer"
+          },
+          "message": {
+            "description": "What is wrong (package findings).",
+            "type": "string"
+          },
+          "name": {
+            "description": "Readable rule or package name.",
+            "type": "string"
+          },
+          "rule": {
+            "description": "Rule id, for yof_explain, yof_fix_prompt and yof_verify.",
+            "type": "string"
+          },
+          "severity": {
+            "description": "fix_now, fix_week or info.",
+            "type": "string"
+          },
+          "value": {
+            "description": "Secret prefix plus REDACTED (key findings).",
+            "type": "string"
+          },
+          "why": {
+            "description": "Why it matters.",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "more": {
+      "description": "How many findings were left out of the list, when there are more than 100.",
+      "type": "integer"
+    },
+    "must_fix_before_done": {
+      "description": "true when at least one fix_now finding is open.",
+      "type": "boolean"
+    },
+    "next": {
+      "description": "What to do next.",
+      "type": "string"
+    },
+    "package_lookups": {
+      "description": "\"off\", or which registries were asked (names and versions only).",
+      "type": "string"
+    },
+    "profile": {
+      "description": "The .yof.yml profile that decided which urgencies are shown.",
+      "type": "string"
+    },
+    "project": {
+      "description": "The folder scanned, relative to the project root.",
+      "type": "string"
+    },
+    "stopped_early": {
+      "description": "true when the file limit was reached before every file was read.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "project",
+    "profile",
+    "files_scanned",
+    "stopped_early",
+    "dependencies_checked",
+    "package_lookups",
+    "counts",
+    "must_fix_before_done",
+    "findings",
+    "next"
+  ],
+  "type": "object"
+}

First observedv0.3.1Nov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses privacy behavior (files read locally, never uploaded; only package names and versions go to npm, PyPI and OSV), config sources (.yof.yml, .gitignore) and hard limits (20,000 files, 500 dependencies, 90 seconds). It also notes that secrets are redacted and that stopped_early flags truncation, which annotations alone 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?

It is front-loaded with purpose then routing then behavior, and no sentence is filler. The single dense paragraph packs many limits together, which is efficient but slightly harder to scan than a short list would be.

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?

For a scanner with an output schema, the description covers everything an agent needs: scope, network behavior, config awareness, resource caps, and the meaning of an empty result. The return-shape summary (counts, must_fix_before_done, up to 100 findings) is a useful complement to the schema rather than a substitute for it.

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?

Schema coverage is 100%, so both parameters are already documented, yet the description adds consequence-level meaning: offline=true means nothing leaves the machine and package problems are then not reported. Path semantics (subfolder scope, refusal outside the project) largely restate the schema, so this is strong but not purely additive.

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?

"Scan the project folder ... for leaked API keys and for made-up, brand-new, lookalike or vulnerable packages" gives a specific verb, resource and detection target. It also names the sibling it differs from (yof_check_diff) so an agent can distinguish a full pass from a diff pass without opening either schema.

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?

It states exactly when to use it ("for a full pass, for example before you say the work is done") and the alternative with its triggering condition ("after small edits use yof_check_diff, which reads only the changed lines"). Both the when and the when-not are explicit.

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

Deploy Server