OpenClueo MCP Server

Server Quality Checklist

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

Latest release: v1.2.20
Disambiguation4/5
Most tools have distinct purposes, but 'inject_personality' and 'inject_preset_personality' could be confusing as they both inject personality into text with only subtle differences. The other tools are clearly separated by function (suggestions, analytics, listing, saving, simulation).
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case, such as 'get_memory_suggestions', 'list_personality_presets', and 'save_project_personality'. This predictability makes the set easy to navigate and understand.
Tool Count5/5
With 7 tools, the server is well-scoped for managing personality traits and configurations. Each tool serves a specific role in the workflow, from listing presets to injecting and simulating personalities, without feeling bloated or sparse.
Completeness4/5
The tool set covers core operations like listing, injecting, saving, and simulating personalities, with good lifecycle coverage. A minor gap is the lack of a tool to delete or update saved project personalities, which might limit agent flexibility in configuration management.
Average 3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 provided, the description carries the full burden of behavioral disclosure. It states the tool 'gets' suggestions, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, returns structured or free-text data, or how it handles missing history. For a tool with potential personalization and no annotations, this is a significant gap in transparency.
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, efficient sentence: 'Get personality suggestions based on context and usage history.' It is front-loaded with the core action and resource, with no wasted words or redundancy. Every part of the sentence contributes directly to understanding the tool's function.
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 complexity of a tool that retrieves personalized suggestions based on history, with no annotations and no output schema, the description is incomplete. It doesn't explain what the suggestions look like (e.g., text, JSON), how personalization works, or error handling. For a tool with two parameters and behavioral nuances, this leaves critical gaps for an agent.
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 description mentions 'context and usage history,' which loosely maps to the 'context' and 'userId' parameters in the schema. However, with 100% schema description coverage, the schema already fully documents both parameters (e.g., 'context' as a string for scenarios like 'customer_email'). The description adds minimal value beyond the schema, so the baseline score 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 clearly states the tool's purpose: 'Get personality suggestions based on context and usage history.' It specifies the verb ('Get') and resource ('personality suggestions'), and distinguishes it from siblings like 'inject_personality' or 'list_personality_presets' by focusing on retrieval rather than application or listing. However, it doesn't explicitly differentiate from 'get_usage_analytics' or 'simulate_response', which slightly reduces specificity.
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 provides no guidance on when to use this tool versus alternatives. It mentions 'based on context and usage history' but doesn't specify prerequisites (e.g., whether usage history must exist), exclusions, or direct comparisons to siblings like 'inject_preset_personality' or 'simulate_response'. This leaves the agent without clear decision-making criteria.
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 mentions using the Clueo API but fails to explain key traits: whether this is a read-only or mutating operation, authentication requirements beyond the optional 'apiKey', potential rate limits, or what the output looks like (e.g., transformed text). This leaves significant gaps for an agent to understand the tool's 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
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 complexity (3 parameters including a nested object for personality traits), no annotations, and no output schema, the description is incomplete. It doesn't explain the behavioral aspects (e.g., mutation, authentication), output format, or differentiation from siblings, leaving the agent with insufficient context for effective use.
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 clear documentation for 'text', 'personality' (including its Big Five dimensions and 1-10 scale), and 'apiKey'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high 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 action ('inject personality traits into text') and specifies the resource ('using Clueo API'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'inject_preset_personality' or 'simulate_response', which appear related to personality/text manipulation, leaving some ambiguity about when to choose this specific tool.
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 provides no guidance on when to use this tool versus alternatives like 'inject_preset_personality' or 'simulate_response'. It lacks context about prerequisites (e.g., needing an API key), use cases, or exclusions, offering minimal help for an agent to make an informed choice among siblings.
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 full burden but only states the basic action without disclosing behavioral traits such as authentication needs (though 'apiKey' hints at optional auth), rate limits, side effects, or output format. It mentions 'enhance' but doesn't clarify what that entails operationally.
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, efficient sentence that front-loads the core purpose without unnecessary words. It earns its place by clearly stating the tool's function in a compact form.
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 complexity of a text transformation tool with no annotations or output schema, the description is insufficient. It lacks details on what 'enhance' means, how the injection works, potential limitations, or example outcomes, leaving gaps for an agent to understand full 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?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying 'text' is enhanced and 'presetId' selects a personality, which aligns with but doesn't exceed schema details. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('inject') and target ('predefined personality preset into text'), making the purpose understandable. It distinguishes from sibling 'inject_personality' by specifying 'preset' usage, though it doesn't fully explain how it differs from that sibling beyond the preset aspect.
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 like 'inject_personality' or 'simulate_response' is provided. The description implies usage for text enhancement with presets, but lacks context on prerequisites, scenarios, 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 provided, the description carries the full burden of behavioral disclosure. It states 'Save' implies a write operation but doesn't clarify if this is destructive (e.g., overwrites existing data), requires authentication, or has side effects like persistence across sessions. This leaves significant gaps in understanding the tool's 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action, making it easy to parse and understand quickly.
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 complexity (4 parameters with nested objects, no annotations, no output schema), the description is insufficient. It doesn't address behavioral aspects like mutation effects, error conditions, or return values, leaving the agent with incomplete context for a tool that likely modifies state.
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 fully documents all parameters. The description adds no additional meaning beyond the schema, such as explaining the relationship between 'projectPath' and 'projectName' or the purpose of 'userId'. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 action ('Save') and resource ('default personality configuration for a specific project'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'inject_personality' or 'inject_preset_personality', which appear related to personality operations but have different verbs.
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 like 'inject_personality' or 'inject_preset_personality'. The description lacks context about prerequisites, such as whether a project must exist or if this overwrites existing configurations, leaving the agent without 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. The description mentions 'simulate' but doesn't clarify what that means operationally: whether this is a read-only simulation, if it has side effects, what authentication is required (though the schema shows an optional apiKey), or what the output format might be. For a tool with no annotations, this leaves significant behavioral questions unanswered.
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, efficient sentence that clearly states the tool's core function. There's no wasted verbiage, and it's appropriately front-loaded with the essential information.
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?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'simulate' means in practice, what the output looks like, or how this differs from related sibling tools. Given the complexity implied by personality trait parameters and the lack of structured behavioral information, the description should provide more context about the tool's operation and results.
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 all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
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: 'Simulate an AI response with specific personality traits'. It specifies the verb ('simulate') and resource ('AI response'), and mentions the key feature ('specific personality traits'). However, it doesn't differentiate from sibling tools like 'inject_personality' or 'inject_preset_personality', which appear related to personality manipulation.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'inject_personality' and 'inject_preset_personality' that seem related to personality traits, there's no indication of when this simulation tool is preferred over those injection tools or other siblings.
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 it 'gets' analytics, implying a read-only operation, but doesn't specify whether this requires authentication, has rate limits, returns structured data, or involves any side effects. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes to understanding what the tool does.
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 has one optional parameter with full schema coverage and no output schema, the description is minimally adequate. It explains what analytics are about but doesn't cover return values, error cases, or behavioral context. For a simple read operation, it meets basic needs but lacks depth for optimal agent use.
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 has 100% description coverage, with the single parameter 'userId' documented as 'Optional user ID to get personalized analytics'. The description doesn't add any meaning beyond this, such as explaining what 'personalized analytics' entails or how usage patterns are defined. With high schema coverage, the baseline score 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 clearly states the verb ('Get') and resource ('analytics about personality usage patterns'), making the purpose understandable. However, it doesn't differentiate this tool from its siblings like 'get_memory_suggestions' or 'simulate_response', which might also involve personality-related operations. The description is specific about what it retrieves but lacks sibling 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or exclusions. Given siblings like 'list_personality_presets' or 'simulate_response', there's no indication of when analytics retrieval is preferred over other personality-related operations.
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 provided, the description carries full burden for behavioral disclosure. It states it's a listing operation but doesn't describe return format, pagination, rate limits, authentication needs, or whether it's a read-only operation. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple listing tool and front-loads the essential information.
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 listing tool with 2 optional parameters and no output schema, the description covers the basic purpose adequately. However, without annotations and with sibling tools that might overlap in functionality, it should provide more context about when this specific listing tool is appropriate versus alternatives.
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 fully documents both parameters. The description doesn't add any parameter semantics beyond what's already in the schema - it doesn't explain how filtering or searching works in practice. This meets the baseline for high schema coverage.
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 ('List') and resource ('all available personality presets'), making the tool's purpose immediately understandable. However, it doesn't differentiate this listing tool from sibling tools like 'inject_personality' or 'inject_preset_personality' that might also involve personality presets, so it doesn't achieve full sibling differentiation.
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 provides no guidance on when to use this tool versus alternatives. There's no mention of when to use 'list_personality_presets' instead of other sibling tools like 'get_memory_suggestions' or 'simulate_response', nor any context about prerequisites or typical use cases.
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:

[![ClueoMCP MCP server](https://glama.ai/mcp/servers/ClueoFoundation/ClueoMCP/badges/card.svg)](https://glama.ai/mcp/servers/ClueoFoundation/ClueoMCP)

Score Badge

Copy to your README.md:

[![ClueoMCP MCP server](https://glama.ai/mcp/servers/ClueoFoundation/ClueoMCP/badges/score.svg)](https://glama.ai/mcp/servers/ClueoFoundation/ClueoMCP)

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/ClueoFoundation/ClueoMCP'

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