VibeRaven

Get a provider playbook

provider_playbook

Read-onlyIdempotent

provider_playbook({"provider":"supabase","topic":"grants"}) Use before implementing a feature that touches a provider, when setup or integration rules are needed. Returns versioned setup guidance, gotchas, dated changes, integration seams, existing repo checks and planned live checks with official sources. Available packs: supabase. Pass topic to return matching items; for a specific error use search_guides, for dated changes use recent_provider_changes. Limits: guidance only; does not connect to providers, read your project, run checks or verify that a feature works.

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": {
      "provider": "<provider>"
    },
    "name": "provider_playbook"
  }
}

Input Schema

Name	Required	Description	Default
`topic`	No	Optional words for the part you need, for example "grants" or "auth redirect". Only matching items are returned; with no match, the whole pack.
`provider`	Yes	Provider id, for example supabase. Unsupported ids return the available packs.

Output Schema

Name	Required	Description	Default
`pack`	Yes
`topic`	No
`nextStep`	Yes
`packHash`	Yes
`provider`	Yes
`packVersion`	Yes
`verification`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026
- addedOutput schema / properties / nextStep / properties / codingAgentTask
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedNov 2, 2026

addedInput schema / properties / topic

Added value: +{
+  "description": "Optional words for the part you need, for example \"grants\" or \"auth redirect\". Only matching items are returned; with no match, the whole pack.",
+  "maxLength": 80,
+  "minLength": 1,
+  "type": "string"
+}

addedOutput schema / properties / topic
```
Added value: +{
+  "type": "object"
+}
```

Changed3 schema fields changedOct 31, 2026
- addedOutput schema / properties / nextStep / properties / accountRequiredForLive
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / nextStep / properties / message
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / nextStep / properties / phase
```
Added value: +{
+  "type": "string"
+}
```
Changed3 schema fields changedOct 31, 2026
- addedOutput schema / properties / nextStep / additionalProperties
```
Added value: +false
```
- addedOutput schema / properties / nextStep / properties
```
Added value: +{
+  "label": {
+    "type": "string"
+  },
+  "url": {
+    "type": "string"
+  }
+}
```
- addedOutput schema / properties / nextStep / required
```
Added value: +[
+  "label",
+  "url"
+]
```
AddedOct 28, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description correctly spends its space elsewhere: it enumerates what the response contains (versioned guidance, gotchas, dated changes, integration seams, existing repo checks, planned live checks, official sources). The explicit limits clause — guidance only, does not connect to providers, read your project, run checks, or verify a feature works — removes the main failure mode of an agent assuming this tool validates anything.

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 body is dense and front-loaded: trigger, payload, alternatives, then limits in a single line. The opening raw invocation example is slightly redundant with the schema's own 'supabase' example and costs a line, but it does orient the caller quickly, so the waste is marginal rather than harmful.

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?

With an output schema present the description need not explain return values, yet it still summarizes them at a level useful for planning. For a two-parameter read-only lookup, the trigger, payload contents, sibling routing and explicit non-capabilities cover everything an agent needs to call it correctly.

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 and the baseline is 3. The description adds value beyond the schema by disclosing the concrete set of supported provider ids (supabase) and by reinforcing that topic acts as a filter whose miss falls back to the whole pack, but it adds no new topic-matching syntax beyond what the schema already says.

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 uses a specific verb-and-resource framing: it returns versioned setup guidance, gotchas, dated changes, integration seams, repo checks and planned live checks for a named provider. It also names the only available pack (supabase) and explicitly distinguishes itself from search_guides and recent_provider_changes, so an agent can separate it from every sibling 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the trigger directly: use before implementing a feature that touches a provider, when setup or integration rules are needed. It then gives two explicit routing alternatives with their conditions — search_guides for a specific error, recent_provider_changes for dated changes — which is exactly the when/when-not/alternative structure that earns a top score.

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

All VibeRaven tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.