companion_detect
Scan a serverless project repo (Supabase / Convex / Cloudflare Workers) and propose a yaver.companion.yaml: token-authed cron endpoints that have no scheduler, missing subscription-reconcile sweeps, and long-running workers. Read-only — never writes the repo. Returns proposed manifest + reasoned ...
This record as markdown: /tools/io-github-kivanccakmak-yaver/companion-detect.md
What companion_detect does on Yaver
AI agents call companion_detect to retrieve information from Yaver without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
repo | string | Yes | Absolute path to the serverless project repo |
Parameters from the server's own tool schema.
Why companion_detect is rated Low
companion_detect performs static analysis and scanning of a serverless project repository to identify configuration issues and propose recommendations. It retrieves and analyzes information (checking for missing schedulers, subscriptions, worker configurations) but explicitly guarantees no write operations. The output is a proposed manifest for review, not an actual modification.
From the tool's definition Tool description explicitly states 'Read-only — never writes the repo' and 'Returns proposed manifest + reasoned items'. The tool scans a repository and analyzes configuration, returning findings without modifying any data.
Attacks that exploit this kind of access
The rule that runs companion_detect safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Yaver, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For companion_detect, this is the rule to start with:
companion_detect is read-only, so it stays allowed. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Yaver, apply this rule, and every companion_detect call is checked against it from then on.
Questions about companion_detect
Scan a serverless project repo (Supabase / Convex / Cloudflare Workers) and propose a yaver.companion.yaml: token-authed cron endpoints that have no scheduler, missing subscription-reconcile sweeps, and long-running workers. Read-only — never writes the repo. Returns proposed manifest + reasoned items. It is categorised as a Read tool in the Yaver MCP Server, which means it retrieves data without modifying state.
companion_detect accepts 1 parameter: repo. Required: repo. The full parameter table on this page comes from the server's own tool schema.
Register the Yaver MCP server in PolicyLayer and add a rule for companion_detect: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Yaver. Nothing to install.
companion_detect is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the companion_detect rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for companion_detect. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
companion_detect is provided by the Yaver MCP server (yaver-cli). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Yaver, and thousands of servers like it.
This server
Across the catalogue