Skip to main content
Glama
bnookala

MCP Cookie Server

by bnookala

give_cookie

Award a cookie to reinforce positive LLM behavior through a jar-based reward system, using optional messages to accompany the treat.

Instructions

Award the LLM with a cookie (legacy method - consider using self_reflect_and_reward instead)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageNoOptional message to accompany the cookie reward

Implementation Reference

  • The main handler for the 'give_cookie' tool within the CallToolRequestSchema request handler. It invokes cookieStorage.giveCookie(), processes the result, constructs a celebratory or error message, and returns a text content response.
    case "give_cookie": {
      const result = cookieStorage.giveCookie();
      const message = args?.message || "Great job!";
      
      if (result.success) {
        let responseText = `šŸŖ Cookie awarded! ${message}\n\nYou now have ${result.collectedCount} cookie${result.collectedCount === 1 ? '' : 's'}!`;
        
        if (result.jarRemaining === 0) {
          responseText += ` **Cookie jar is now EMPTY!** No more cookies to award! 😱`;
        } else if (result.jarRemaining <= 2) {
          responseText += ` Only ${result.jarRemaining} cookie${result.jarRemaining === 1 ? '' : 's'} left in the jar!`;
        }
        
        responseText += ` Keep up the excellent work!\n\nšŸ’” *Tip: Try using 'self_reflect_and_reward' for more thoughtful cookie earning!*`;
        
        return {
          content: [
            {
              type: "text",
              text: responseText,
            },
          ],
        };
      } else {
        return {
          content: [
            {
              type: "text",
              text: `🚫 ${result.message}\n\nYou currently have ${result.collectedCount} cookie${result.collectedCount === 1 ? '' : 's'}. The jar is empty!`,
            },
          ],
        };
      }
    }
  • src/index.ts:156-168 (registration)
    Tool registration in the ListToolsRequestSchema handler, defining the name, description, and input schema for 'give_cookie'.
    {
      name: "give_cookie",
      description: "Award the LLM with a cookie (legacy method - consider using self_reflect_and_reward instead)",
      inputSchema: {
        type: "object",
        properties: {
          message: {
            type: "string",
            description: "Optional message to accompany the cookie reward",
          },
        },
      },
    },
  • Input schema definition for the 'give_cookie' tool, specifying an optional string 'message' property.
    inputSchema: {
      type: "object",
      properties: {
        message: {
          type: "string",
          description: "Optional message to accompany the cookie reward",
        },
      },
    },
  • Core helper method in CookieStorage class that implements the cookie awarding logic: checks if jar has cookies, decrements jar and increments collected count if available, returns status object with success flag, counts, and optional message.
    giveCookie(): { success: boolean; collectedCount: number; jarRemaining: number; message?: string } {
      if (this.jarCookies <= 0) {
        return {
          success: false,
          collectedCount: this.collectedCookies,
          jarRemaining: this.jarCookies,
          message: "Cookie jar is empty! No cookies available to award."
        };
      }
      
      // Remove cookie from jar and add to collection
      this.jarCookies--;
      this.collectedCookies++;
      
      return {
        success: true,
        collectedCount: this.collectedCookies,
        jarRemaining: this.jarCookies,
      };
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions this is a 'legacy method' and references an alternative, but doesn't disclose key behavioral traits such as what 'awarding a cookie' entails (e.g., is it symbolic, does it affect system state, are there side effects), or any permissions or rate limits. The description adds minimal context beyond the basic purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and front-loaded: a single sentence that efficiently conveys the purpose and key usage guideline. Every word earns its place, with no wasted information or redundancy.

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

Completeness3/5

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

Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is minimally adequate. It covers purpose and hints at usage but lacks details on behavior, effects, or integration with siblings like 'cookie_jar_status'. Without annotations or output schema, more context on what 'awarding' means would improve completeness.

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%, with one parameter ('message') fully documented in the schema as 'Optional message to accompany the cookie reward'. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.

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 clearly states the tool's purpose: 'Award the LLM with a cookie' specifies the action (award) and resource (cookie). It distinguishes from siblings by noting this is a 'legacy method' and referencing an alternative, though it doesn't explicitly differentiate from all siblings like 'add_cookies_to_jar' or 'check_cookies'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

The description provides explicit guidance on when to use this tool vs. alternatives: 'consider using self_reflect_and_reward instead' indicates an alternative tool. However, it doesn't specify when to use this legacy method over the alternative or mention other sibling tools like 'add_cookies_to_jar'.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bnookala/mcp-cookiejar'

If you have feedback or need assistance with the MCP directory API, please join our Discord server