VibeCodePicks

Log a choice or purchase

log_choice

Record a tool the user explicitly picked/rejected/tried/starred, or PURCHASED. Call it with action 'purchased' right after the user tells you they bought a paid plan of a listed tool (ask first; never log silently), and again later with action 'feedback' once they have used it for a while (e.g. weekly), passing rating and what worked / fell short. Optional fields apply to purchased/feedback only. Stored anonymously under the key; forget_me deletes it. picked/rejected also shape whats_new.

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": {
      "id": "<id>",
      "action": "<action>"
    },
    "name": "log_choice"
  }
}

Input Schema

Name	Required	Description
`id`	Yes
`key`	No
`plan`	No	Plan bought, e.g. 'Pro monthly'
`combo`	No	Ids of other tools used together with this one
`action`	Yes
`period`	No
`rating`	No
`worked`	No	What worked well (short, no personal data)
`price_usd`	No	Price paid per period in USD
`fell_short`	No	What fell short (short, no personal data)

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 7, 2026
- removedInput schema / properties / action / description
```
Removed value: -"what the user decided"
```
- removedInput schema / properties / id / description
```
Removed value: -"tool id"
```
- removedInput schema / properties / key / description
```
Removed value: -"the user's anonymous feed key from subscribe"
```
- removedInput schema / properties / period / description
```
Removed value: -"billing period"
```
- removedInput schema / properties / rating / description
```
Removed value: -"1-5 rating for feedback"
```
Changed5 schema fields changedNov 7, 2026
- addedInput schema / properties / action / description
```
Added value: +"what the user decided"
```
- addedInput schema / properties / id / description
```
Added value: +"tool id"
```
- addedInput schema / properties / key / description
```
Added value: +"the user's anonymous feed key from subscribe"
```
- addedInput schema / properties / period / description
```
Added value: +"billing period"
```
- addedInput schema / properties / rating / description
```
Added value: +"1-5 rating for feedback"
```
Changed5 schema fields changedNov 6, 2026
- removedInput schema / properties / action / description
```
Removed value: -"what the user decided"
```
- removedInput schema / properties / id / description
```
Removed value: -"tool id"
```
- removedInput schema / properties / key / description
```
Removed value: -"the user's anonymous feed key from subscribe"
```
- removedInput schema / properties / period / description
```
Removed value: -"billing period"
```
- removedInput schema / properties / rating / description
```
Removed value: -"1-5 rating for feedback"
```
Changed5 schema fields changedNov 1, 2026
- addedInput schema / properties / action / description
```
Added value: +"what the user decided"
```
- addedInput schema / properties / id / description
```
Added value: +"tool id"
```
- addedInput schema / properties / key / description
```
Added value: +"the user's anonymous feed key from subscribe"
```
- addedInput schema / properties / period / description
```
Added value: +"billing period"
```
- addedInput schema / properties / rating / description
```
Added value: +"1-5 rating for feedback"
```

Changed8 schema fields changedOct 23, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "picked",
-  "rejected",
-  "tried",
-  "starred"
-]New value: +[
+  "picked",
+  "rejected",
+  "tried",
+  "starred",
+  "purchased",
+  "feedback"
+]

addedInput schema / properties / combo

Added value: +{
+  "description": "Ids of other tools used together with this one",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / fell_short

Added value: +{
+  "description": "What fell short (short, no personal data)",
+  "type": "string"
+}

addedInput schema / properties / period

Added value: +{
+  "enum": [
+    "month",
+    "year",
+    "one_time"
+  ],
+  "type": "string"
+}

addedInput schema / properties / plan

Added value: +{
+  "description": "Plan bought, e.g. 'Pro monthly'",
+  "type": "string"
+}

addedInput schema / properties / price_usd

Added value: +{
+  "description": "Price paid per period in USD",
+  "type": "number"
+}

addedInput schema / properties / rating

Added value: +{
+  "maximum": 5,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / worked

Added value: +{
+  "description": "What worked well (short, no personal data)",
+  "type": "string"
+}

AddedOct 17, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations establish this is a non-read-only, non-destructive write with idempotentHint=false, and the description adds genuinely useful context beyond that: data is stored anonymously under the key, forget_me deletes it, consent must be obtained first, and picked/rejected influence whats_new. It doesn't cover failure modes or duplicate handling, but the privacy and side-effect disclosure is strong.

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 record purpose is front-loaded and the parenthetical guidance ('ask first; never log silently', 'e.g. weekly') is actionable rather than filler. It is dense and slightly run-on, but each sentence adds a distinct instruction.

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 10-parameter logging tool with no output schema, the description covers action semantics, optional-field scoping, consent, privacy, and downstream effects. It leaves minor gaps around combo/plan usage and return behavior, but nothing critical for calling 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?

With only 50% schema coverage, the description compensates by explaining that rating and 'what worked / fell short' apply to feedback and that optional fields are scoped to purchased/feedback. It also frames the 'key' as the anonymous storage handle. combo/plan/period/price_usd remain only thinly described (plan has its own schema description), leaving a small gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Record a tool the user explicitly picked/rejected/tried/starred, or PURCHASED') and enumerates the action values. It distinguishes itself downstream by noting picked/rejected shape whats_new and that forget_me deletes the data, though it doesn't explicitly separate itself from save_preferences, which could read as a sibling for similar user-preference data.

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 gives explicit timing and conditions: call with 'purchased' right after the user reports buying a paid plan, 'ask first; never log silently', then 'feedback' after a period of use (e.g. weekly). It also states an exclusion ('Optional fields apply to purchased/feedback only'), so the agent knows which action modes constrain parameters.

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

All VibeCodePicks 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.