whimsicality-mcp

Official

by WhimsicalityLabs

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Most tools have distinct purposes: facts, context slots, RAG search, plans, snippets, and compaction each serve different needs. However, facts and context both act as persistent key-value stores, which could cause some confusion, though the descriptions clarify context as memory and facts as factual data.
Naming Consistency4/5
The naming follows a consistent pattern of 'whim_<resource>_<action>' for most tools (e.g., whim_facts_get, whim_context_set, whim_rag_search). Minor exceptions include whim_compact, which lacks a resource category, and slight verb placement variations, but overall the pattern is predictable.
Tool Count4/5
14 tools is a reasonable count for a multi-purpose memory and utility server. Each tool covers a distinct functional area, though some areas like facts and context could potentially be merged, but the count is within the well-scoped range and does not feel excessive.
Completeness3/5
The server covers core operations for facts, context, and RAG, but has notable gaps: no delete for facts, plans, or snippets; no list for plans or snippets; and no way to retrieve a snippet by name (only search). These missing operations may force agents to work around or leave orphaned data.
Average 3.3/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior, but it only states the operation. It does not disclose what happens if the fact does not exist (e.g., error vs. empty result), whether the operation is read-only, or any side effects. The read-only nature is implied but not explicitly stated.
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 description is a single, concise sentence with no filler. It is front-loaded and easy to parse, but it is so minimal that it borders on under-specification, missing contextual detail without becoming verbose.
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?
For a simple tool with one parameter and no output schema, the description is minimally adequate. However, it omits behavior on missing facts and any distinctions from similar tools, leaving some gaps in completeness given the sibling context.
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?
The schema already fully documents the single parameter 'name' with description 'Fact name', achieving 100% coverage. The description adds no additional meaning beyond what the schema provides, so the baseline of 3 applies.
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 'Retrieve a named fact' clearly states the action (retrieve) and the resource (fact), with the qualifier 'named' indicating lookup by name. It distinguishes from sibling tools like whim_facts_save and whim_facts_list, though it could be more explicit about the store context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as whim_facts_list or whim_facts_save. There is no mention of prerequisites, typical use cases, or conditions that would make this tool preferable over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and the description does not disclose any behavioral traits such as read-only nature, potential side effects, permissions required, or rate limits. Since this is a list operation, it likely reads data, but this is not explicitly stated.
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 a single, focused sentence that directly states the tool's purpose. It is concise and free of redundant details, effectively communicating the essence.
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?
While the description indicates the tool lists fact names, it does not specify the return format (e.g., array, object), nor does it mention potential edge cases, errors, or sorting/order. Given no output schema is provided, these details are missing, though the core behavior is understandable.
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?
The tool has no parameters, and the schema already fully describes this (empty properties). The description adds no parameter-related information, which is acceptable given the trivial case, but it does not go beyond the schema to provide any additional clarity.
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 clearly states the action (list), the resource (saved fact names), and the scope (all). It directly conveys the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., whim_facts_get for a single fact, or list operations for other resources). The description lacks any mention of suitable contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'retrieve a saved plan,' which implies a read operation without elaborating on return values, error behavior, or side effects. It does not disclose what happens if the plan does not exist or how the 'name' parameter affects retrieval beyond the schema. This is insufficient for a tool with no annotation support.
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 description is a single, concise sentence that immediately conveys the tool's purpose without redundancy. It is front-loaded and efficient, though it could be slightly more descriptive without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, an output schema, and any explanation of what a 'plan' entails, the description is incomplete. It provides no context on expected return format, failure conditions, or how this tool relates to sibling plan-related tools. A more complete description would clarify the concept of a 'plan' and outline basic usage behavior.
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?
The single parameter 'name' is fully documented in the schema with its default value, so schema coverage is 100%. The description adds no extra meaning to the parameter, aligning with the high-coverage baseline of 3. It neither clarifies the parameter's purpose beyond the schema nor introduces any additional context.
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 verb 'retrieve' and the resource 'saved plan', which accurately conveys the tool's function. It distinguishes well from the sibling tool whim_plan_save (save vs. retrieve), though it could be slightly more specific about what constitutes a 'plan'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other getters like whim_facts_get or whim_context_get. There is no mention of alternatives, prerequisites, or context for using the default 'current' parameter. The description is purely a statement of action without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It does not mention whether the tool is read-only, what happens if the key does not exist, whether it returns an error or empty string, or any side effects. The description is minimal and lacks behavioral context.
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 description is a single, concise sentence that is front-loaded with the action and resource. It is efficient with no wasted words, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description is minimal but lacks important context such as behavior on missing keys, namespace semantics, and relationship to other retrieval tools. With no annotations and no output schema, the description should provide more guidance on expected behavior and return values.
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%, so the schema already documents both parameters ('key' and 'namespace'). The description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.
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 'Retrieve text from a named context slot' clearly states the action (retrieve) and the resource (named context slot). It distinguishes from siblings like whim_context_set (write) and whim_context_list (list all), though it doesn't explicitly differentiate from whim_facts_get or whim_rag_search which also retrieve information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving stored context by name, but provides no explicit guidance on when to use this tool versus alternatives like whim_facts_get or whim_rag_search. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of disclosure. It only says 'search' which implies read-only, but does not state that it does not modify data, what it returns (e.g., list of snippets), or any other behavioral details. The description adds no beyond the basic action.
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 description is a single sentence with no wasted words. It conveys the core purpose efficiently. While it is minimal, it is not bloated or redundant, and there is no filler content. It is appropriately concise for a simple search tool, though it could be more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (search with two parameters), but there is no output schema, so the description should explain the return format or at least mention that it returns matching snippets. It does not. It also lacks context about the nature of snippets (e.g., saved via whim_snippet_save). The description is too terse to be considered complete for an agent to know what to expect from the call.
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% (both 'query' and 'topK' are described in the schema). The description itself adds no parameter-specific information, only the phrase 'keyword overlap' which hints at query matching but does not clarify syntax or defaults. Since the schema covers the parameters, the description adds minimal value, consistent with the baseline of 3 for full schema coverage.
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 clearly states the tool's function: searching saved snippets by keyword overlap. It uses a specific verb ('search') and resource ('saved snippets'), and the method ('keyword overlap') distinguishes it from sibling tools like whim_rag_search, which likely searches a different index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or contrast with whim_rag_search or other search tools. The description is a bare statement of purpose without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It does not reveal whether the operation is read-only, what the return format is, or any side effects. For a read-like list operation, it might be implicitly safe, but the description does not state this.
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 description is a single, clear sentence with zero wasted words. It is appropriately concise for a simple list operation, though it is terse and could include more context.
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?
For a simple tool with one optional parameter and no output schema, the description is minimal but arguably sufficient. However, it lacks details about the output format (e.g., if it returns keys only or key-value pairs) and any behavioral notes, which 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 coverage is 100% for the single optional 'namespace' parameter, which already has a description including the default value. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
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 clearly states the action ('List all context slot keys'), specifying the resource (context slots) and scope (all keys). It distinguishes from sibling tools like whim_context_get (which retrieves a value) and whim_context_set (which sets a value).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that it is for discovering available keys or that other tools should be used for specific operations. The description simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It states that facts persist across sessions, which is useful, but it does not describe what happens when saving an existing fact name (overwrite behavior), any restrictions on names/values, or the nature of the response. For a save/write operation, an agent needs more behavioral cues.
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?
Two short sentences with no fluff. The core action and a clarifying definition of the payload are front-loaded, making the description easy to parse.
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?
The tool is simple (2 string params, no nested objects, no output schema) and the description covers the basic operation. Still, the agent would benefit from knowing overwrite behavior and how this differs from other 'save'-type siblings like whim_context_set, so it is minimally viable but not complete.
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%, and both 'name' and 'value' are explained with a concrete example for the name. The description itself adds the 'key-value pairs' framing, but the schema already carries the essential parameter meaning, so the tool description does not need to compensate.
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 verb ('Save') and resource ('a named fact'), and clarifies that facts are key-value pairs. It does not explicitly differentiate from sibling tools like whim_context_set, but the tool name and 'fact' terminology reasonably convey its distinct scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit 'when to use vs alternatives' guidance is given. However, describing facts as 'key-value pairs that persist across sessions' implies the intended use — storing stable named facts for later retrieval. There is no mention of when not to use this tool or how it compares to context or plan saving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Save' without indicating whether it overwrites existing snippets, requires specific permissions, or has side effects like deduplication. The write nature is implied but not detailed.
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 a single, concise sentence with no unnecessary words. It efficiently conveys the core purpose without fluff.
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?
For a simple save operation, the description is moderately complete. It lacks details about return values (though no output schema exists) and error scenarios, but the basic action is clear. Given the simplicity of the tool, this level of completeness is acceptable.
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?
The schema provides short descriptions for each parameter ('Snippet code', 'Snippet name', etc.), and the tool description does not add further meaning. Since schema coverage is 100%, the baseline is 3, but the descriptions are too terse to give higher marks.
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 clearly states the action ('Save') and the resource ('reusable code snippet'). It distinguishes the tool from siblings like whim_snippet_search (search) and whim_facts_save (save facts) by focusing on code snippets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It fails to mention that this should be used for creating or updating snippets, or to compare with similar save operations like whim_facts_save.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosure burden. For a destructive operation, there is zero behavioral disclosure: no mention that the operation permanently removes data, no mention of idempotency, no note about what happens to the slot's contents or any cascading effects. The description is merely a label that adds no transparency beyond the name, and absent annotations, this is a significant gap for a destructive call.
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?
Three words and a period, with the verb front-loaded. Zero filler, zero redundancy. For a simple CRUD delete where the schema covers all parameters, extreme leanness is appropriate and not under-specification. It fully adheres to 'every sentence earns its place' by having exactly one minimal sentence.
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 low-complexity tool (2 params, no enums, no nested objects, no output schema) with 100% schema coverage, the description is arguably just enough: the schema documents both parameters, the siblings define the CRUD family, and the verb defines the action. Minor deduction: a warning about the destructive nature of the operation or its namespace scoping would push this to a 5, but completeness is relative to a deliberately simple tool.
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?
The schema already covers 100% of parameters with precise descriptions (key = "Context slot name", namespace with default "default"), so the baseline is 3. The description "Delete a context slot" adds no additional parameter semantics — it doesn't clarify how key and namespace interact, nor the semantics of passing no namespace (e.g., is a key deleted globally or within the default namespace?). No value-add beyond schema, but no harm either.
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 uses a precise verb ("Delete") and resource ("context slot"), and is clearly distinct from siblings like whim_context_get/set/list. The verb disambiguates it within the CRUD family and the tool name reinforces the same contract. Slight deduction: "context slot" is opaque without further explanation, and it's unclear whether the deletion is scoped per-namespace or if the action is cryptographically irreversible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied by the sibling CRUD pattern (get/set/list/delete for context), so an agent can infer when this applies. However, there is zero explicit guidance about edge cases or exclusions — what happens if the supplied key doesn't exist? Is deletion permanent and irreversible? No mention of whether the namespace parameter is required to target the correct slot. The description leaves the agent to assume from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only says 'Index a document' without disclosing side effects, persistence, idempotency, or behavior on re-indexing with the same ID. This minimal disclosure offers little beyond the tool name.
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 a single sentence with zero wasted words. It front-loads the action and purpose efficiently, making it easy to parse quickly.
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 simple tool with two well-documented parameters and no output schema, the description is mostly complete. It covers the basic action and purpose. However, it could be improved by noting idempotency or overwrite behavior, but that is minor given its simplicity.
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?
The input schema fully describes both parameters (id and text) with 100% coverage, so the baseline for param semantics is 3. The description does not add extra meaning beyond the schema, but it also doesn't need to since the schema is sufficient.
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 clearly states the tool indexes a document for keyword search retrieval, which is a specific verb+resource action. It distinguishes from sibling tool whim_rag_search (which retrieves) and other whim_* tools by its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, such as directing to index before calling whim_rag_search. The description implies indexing is a prerequisite but never states it directly or mentions exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the core behavior—keyword overlap, word-boundary ranking, and chunk returns—so an agent knows it is a read-style retrieval operation. However, it omits details like pagination, result fields, or any limits, leaving some ambiguity about behavior.
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 one concise, front-loaded sentence that names the action, target, and return behavior without unnecessary words. Every phrase contributes meaningful information.
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?
The tool is simple (2 params, no nested objects), so the description covers the essential behavior: searching indexed documents and returning ranked chunks. Without an output schema, a bit more detail about the exact return structure or default behavior would improve completeness, but the current description is sufficient for a basic retrieval tool.
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%, so the schema already documents both parameters (query and topK). The description adds contextual meaning by explaining that matching is keyword-overlap based and ranked, but it does not add new parameter-level semantics beyond the schema.
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 function: search indexed documents by keyword overlap and return relevant chunks ranked by match score. It identifies the resource ('indexed documents') and the mechanism ('word-boundary match score'), making it distinct from sibling tools like fact or context retrieval, though it doesn't explicitly name that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as whim_snippet_search or whim_facts_get. The description implies a keyword-overlap search use case, but it does not state exclusions, prerequisites, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It does disclose that writes persist across sessions, which is meaningful behavioral context. However, it omits other important behaviors like overwrite semantics on an existing key, any synchronization effects, or error conditions, leaving gaps for an agent deciding to invoke a write operation.
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?
Two tightly written sentences with zero wasted words. The first sentence front-loads the action; the second justifies existence with the persistence angle. Every word earns its place.
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?
For a 3-parameter write tool with no output schema, the description adequately covers the essentials. However, given the crowded sibling space (facts, snippets, RAG search all similar stores), and no annotation fallback, some guidance on behavior on overwrite or relationship to sibling stores would round out completeness. Not inadequate, but with clear room to grow.
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 every parameter (key, text, namespace) documented inline. Per the rubric, high coverage sets a baseline of 3. The description's mention of a "named context slot" reinforces the key parameter's purpose but adds little beyond the schema's own descriptions.
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?
"Store text in a named context slot" is a specific verb+resource pairing that clearly explains the operation. The set/get/list/delete CRUD family among siblings is naturally distinguished, though the description doesn't explicitly differentiate from other persistent stores like whim_facts_save or whim_snippet_save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use for persistent memory that survives across agent sessions" gives clear context on when to use the tool. However, with 12 siblings including whim_facts_save and whim_snippet_save that also persist data, the description offers no alternatives, exclusions, or disambiguation about when to pick context over facts or snippets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses persistence across sessions and cross-agent retrievability, but it does not mention overwrite semantics for the same plan name or any side effects. The description is honest but lacks depth on behavioral nuances.
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 exactly two sentences, front-loaded with the action and purpose, with no wasted words. It is exemplary in conciseness.
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 simple save tool with a fully documented schema and no output schema, the description covers the essential contextual information: persistence and cross-agent retrieval. It misses minor details like overwrite behavior, but overall it is sufficient for a tool of this complexity.
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%, so the parameters are already fully documented. The description adds no extra meaning beyond what the schema provides, which aligns with the baseline of 3 for high schema coverage.
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 clearly states the action (save) and resource (plan document), and the persistence and cross-agent retrieval details distinguish it from sibling tools like whim_plan_get. It is specific and unambiguous.
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 implies usage when you need to persist a plan for later retrieval by another agent, providing context but no explicit exclusions or comparisons to alternatives like whim_facts_save or whim_snippet_save. It gives clear context without spelling out when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It does so by explaining the exact operation: 'Keeps first and last messages intact, truncates the middle.' This gives the agent a clear understanding of what will happen, though it does not mention any potential data loss or irreversibility.
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 two concise sentences, front-loaded with the primary purpose and followed by key behavioral details and a clarifying caveat. Every sentence adds value with no wasted words.
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?
Given the tool's simplicity (two parameters, no nested objects) and the behavioral detail provided, the description is fairly complete. It explains the operation, the preservation rule, and a caveat. It does not describe the return value, but for a simple transformation tool this is likely sufficient.
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?
The schema already thoroughly describes both parameters with 100% coverage. The description adds context about token budget targets but does not enrich the semantics of individual parameters meaningfully. A score of 3 is appropriate as the schema carries the load.
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 clearly states the tool's verb and resource: 'Truncate conversation history to fit a token budget.' It further clarifies scope by noting 'Keeps first and last messages intact, truncates the middle,' which distinguishes it from generic compaction or summarization tools.
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 an explicit use case: 'to fit a token budget.' It also differentiates from summarization with 'This is truncation, not summarization.' However, it does not name alternatives or explicitly state when not to use it, but the guidance is sufficient for most situations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Whimsicality-MCP MCP server](https://glama.ai/mcp/servers/WhimsicalityLabs/Whimsicality-MCP/badges/card.svg)](https://glama.ai/mcp/servers/WhimsicalityLabs/Whimsicality-MCP)

Score Badge

Copy to your README.md:

[![Whimsicality-MCP MCP server](https://glama.ai/mcp/servers/WhimsicalityLabs/Whimsicality-MCP/badges/score.svg)](https://glama.ai/mcp/servers/WhimsicalityLabs/Whimsicality-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/WhimsicalityLabs/Whimsicality-MCP'

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