Lanonasis MCP Server

Official

by lanonasis

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action. Memory tools clearly separate get (by ID), search (semantic), and list (paginated) operations, while API keys, projects, config, and status tools are uniquely scoped. No two tools overlap significantly.
Naming Consistency5/5
All 17 tools follow a consistent verb_noun snake_case pattern, using plural nouns for list/search and singular for point operations. Verb choices are clear (create, get, update, delete, list, search, rotate, set). No mixing of conventions.
Tool Count4/5
At 17, the tool count is slightly above the typical 3-15 range, but the breadth of domains (memories, API keys, projects, config, status) justifies the extra tools. It feels well-scoped for a general-purpose backend server.
Completeness3/5
Memory management is fully covered with CRUD plus search. API key lifecycle is also solid. However, project support only includes create and list—no get, update, or delete—leaving a notable gap in the project resource lifecycle.
Average 2.7/5 across 17 of 17 tools scored. Lowest: 1.5/5.
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 is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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, but it fails to mention any side effects, required permissions, uniqueness constraints, or other behavioral traits beyond the creation act itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. It consists of a single sentence that simply restates the tool name, contributing no useful structure or information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and no output schema, the description is severely inadequate. An agent would have no guidance on how to construct a valid request or understand the tool's effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description adds no explanation for the parameters (name, description, organization_id). It does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new project' is a direct restatement of the tool name 'create_project', providing no additional information about the tool's purpose or distinguishing it from sibling tools in any meaningful way.
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 gives no guidance on when to use this tool versus alternatives, nor any context such as prerequisites or typical use cases. It simply repeats the action.
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?
With no annotations provided, the description carries the full burden of disclosing behavior, but it does not state whether the operation is read-only, what it returns, whether it makes network calls, or any side effects. The agent gets zero behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It fails to convey any meaningful detail that would help an agent select or invoke the tool correctly, so the single sentence does not 'earn its place'.
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 is likely simple (no parameters), a minimal description could suffice, but this one still lacks essential context: what does 'authentication status' include? What is the return shape? Without an output schema to fill this gap, the description is inadequate for an agent to understand what it will receive.
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?
The tool has zero parameters and the input schema is an empty object, so per the rubric the baseline is 4. The description adds no parameter info, but none is needed since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get authentication status' is a near-verbatim restatement of the tool name, providing no additional specificity about what 'authentication status' actually encompasses (e.g., token validity, user identity, expiry). It does not distinguish itself from sibling status tools like get_health_status or get_organization_info.
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?
The description offers no guidance on when to use this tool vs. alternatives, nor does it specify prerequisites or typical scenarios (e.g., checking if a token is valid before making authenticated calls). It is completely silent on usage context.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention persistence, overwriting behavior, scope, side effects, error conditions, or required permissions. For a mutation tool, this is a complete absence of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than effective conciseness. The single sentence provides no useful information beyond the tool name and does not earn its place as a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two simple parameters and full schema coverage, the tool is not inherently complex, but the description still fails to provide essential context such as the effect of setting a config value, whether it updates an existing setting, or what the expected outcome is. The description is completely inadequate for an agent to invoke this tool confidently.
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 baseline is 3. The description adds no meaning beyond the schema: it simply says 'configuration setting' while 'key' and 'value' are already documented as 'Configuration key' and 'Configuration value'. No additional parameter context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set configuration setting' essentially restates the tool name 'set_config', providing no additional specificity about what kind of configuration or which settings. It is a tautology rather than a clear statement of purpose that distinguishes this tool from siblings like get_config.
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?
There is no guidance on when to use this tool versus alternatives. The sibling list includes get_config, which suggests a read counterpart, but the description gives no context about when setting a config value is appropriate or what prerequisites might exist.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states only 'List projects' and reveals nothing about read-only nature, pagination, return format, or filtering behavior. This is a complete lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words, which is technically concise, but it is severely under-specified. It is not effective conciseness but rather an absence of content, similar to the 'process' example. Every sentence should earn its place; here the only sentence is an obvious restatement.
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 description is incomplete even for a low-complexity tool. With no annotations, no output schema, and minimal parameter schema, the description should at least state basic listing behavior, but it provides no contextual information about how projects are returned or filtered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, organization_id, with no description and 0% schema description coverage. The tool description does not mention this parameter or explain its purpose or effect. No effort is made to compensate for the schema's lack of semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and resource 'projects', unambiguously stating the operation. It distinguishes from sibling tools like create_project and other list tools by resource type, making the purpose clear despite being terse.
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 usage guidance is provided. The description does not mention when to use this tool, how it relates to alternatives, or the optional organization_id parameter that could filter results. It offers no context for agent decision-making.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without addressing side effects, required permissions, return value, or rate limits. The presence of 5 parameters and an enum makes this omission severe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified for a tool with 5 parameters. It front-loads the purpose but omits necessary details, making it not appropriately sized for the tool's complexity.
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 moderate complexity (5 parameters), lack of annotations, and lack of output schema, the description is far from complete. It only covers the basic action, leaving out return format, required fields beyond name, and operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only 20% description coverage (only 'name' has a description). The tool description adds no parameter meaning, failing to explain project_id, access_level, or expires_in_days. This fails to compensate for the low 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 'Create a new API key' clearly specifies the verb (create) and resource (API key), making it distinct from sibling tools like create_memory or create_project. 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 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 such as rotate_api_key or list_api_keys. It lacks context on prerequisites (e.g., whether project_id is required) and does not mention any exclusions.
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?
With no annotations, the description must fully disclose behavior. It only states 'Update an existing memory' without indicating whether it merges fields or replaces content, what happens if the ID does not exist, or any permission requirements. This is minimal disclosure even for a mutation tool.
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, front-loaded sentence with no unnecessary words. It is concise, though the brevity borders on under-specification, but structure and clarity of phrasing are good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is severely incomplete. It lacks information about return values, error behavior, default update semantics (e.g., merge vs. replace), and any side effects, leaving the agent with insufficient guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'id' has a description), and the tool description does not mention any parameters. It adds no meaning beyond the raw schema, leaving tags, title, content, and memory_type undefined.
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 with a specific verb and resource: 'Update an existing memory.' It distinguishes itself from sibling tools like create_memory, delete_memory, and get_memory by explicitly focusing on updating an existing entity.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, such as requiring an existing memory ID, nor does it differentiate from create_memory or clarify partial vs. full updates.
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 disclosure, but it only repeats the tool's name. It does not state that listing is read-only, what the response format is, or whether pagination or filtering options exist. This lack of behavioral context is a significant gap.
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 extremely concise and front-loaded with the key action and resource. It is not padded, but it could be more informative without losing efficiency. Still, it earns a high score for 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 has two optional parameters and no output schema, so the description should compensate with parameter explanations and expected behavior. It does not, leaving the tool incomplete for real-world invocation. The sparse description is insufficient for a tool with even minimal complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters with no descriptions, and the description does not mention them at all (0% schema coverage). The agent cannot infer the meaning of project_id or active_only from the tool description, making parameter usage ambiguous.
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 ('List') and resource ('API keys'), which distinguishes it from siblings like create_api_key, rotate_api_key, and delete_api_key. However, it does not clarify scope (e.g., whether it lists keys for all projects or a specific project), which would be more informative.
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 get_api_key or list_projects. There is no mention of prerequisites or typical use cases, leaving the agent without context for selecting this tool.
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 must carry the full burden of behavioral disclosure. It does not mention whether the search is read-only, how results are ordered, or any side effects. The phrase 'semantic vector search' describes method but not behavior like return format or pagination.
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?
One sentence with no redundancy. It is appropriately concise, though it sacrifices substance. The structure is a simple declarative statement, which is efficient but lacks any preparatory or explanatory context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (5 parameters, no output schema, no annotations), but the description provides minimal context. It does not explain the return format, threshold semantics, or how memory_type filters results. This is inadequate for an agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'query' has a description). The tool description adds no details about 'tags', 'limit', 'threshold', or 'memory_type'. With this low coverage, the description must compensate but does not, leaving most parameters undefined.
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: 'Search through memories' with the specific method 'semantic vector search'. The verb + resource is specific, and the semantic vector search differentiates it from the sibling tool list_memories, which likely returns all memories.
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 gives no guidance on when to use this tool versus alternatives like list_memories. There is no mention of appropriate scenarios, exclusions, or preferred conditions. The usage context is only implied by the phrase 'Search through memories'.
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?
There are no annotations, so the description must disclose behavioral traits. It only says 'Get configuration settings' without explaining behavior like whether the key parameter is optional, what happens if the key is not found, or what the return format looks like. This is insufficient for an agent to understand the tool's full 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 concise sentence that directly states the tool's purpose. It is appropriately sized for the tool's simplicity and contains no unnecessary words.
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 has no output schema, so the description should clarify what the tool returns or how it behaves, but it does not. It also lacks mention of related tools or usage context. The low complexity and single parameter reduce the burden, but the description still leaves out key details about return values and optional 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 schema includes a clear description for the 'key' parameter ('Specific config key to retrieve'), and with 100% schema description coverage, the description adds no additional meaning. The baseline score of 3 is appropriate since the schema already carries the semantic weight.
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 identifies the tool as a getter for configuration settings, distinguishing it from the sibling set_config. However, it is somewhat generic and could be more specific about whether it retrieves all settings or a single key, though the schema hints at that.
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. It does not mention that set_config should be used for modifications, nor any context for when retrieving configuration is appropriate. The description is a bare statement with no situational direction.
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?
No annotations are present, so the description carries the full burden. It mentions pagination and filters, which are behavioral capabilities, but does not disclose data scoping (e.g., user-scoped vs global), ordering, or rate limits. For a benign list operation, this is minimal but not entirely absent.
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, front-loaded sentence with no wasted words. It is concise and structurally clear, though it lacks some detail—this is a completeness issue rather than a conciseness problem.
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 no output schema and no annotations, the description is quite short. It does not state the return format, sorting, or pagination defaults, nor does it clarify the relationship to search_memories. For a 4-parameter tool, this is insufficient as a standalone guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only says 'with pagination and filters' without mapping tags/memory_type to filters or limit/offset to pagination. Parameter names are self-explanatory, but the description does not clarify semantics like tag filtering behavior (AND/OR) or accepted values for memory_type.
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 lists memories with pagination and filters, which distinguishes it from get_memory (single retrieval) and search_memories (search-based). However, it does not explicitly differentiate from search_memories, so it is clear but not fully distinguished.
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 search_memories or other siblings. The description does not explain the appropriate context for listing vs searching, leaving the agent to infer usage.
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 behavioral traits. 'Rotate an API key' is vague and does not specify whether the old key is invalidated, whether a new key is returned, or if the operation is reversible. For a mutation tool, this is a significant transparency gap.
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, front-loaded sentence that states the core action without unnecessary words. While it could include more detail without becoming verbose, the extreme brevity is a strength in terms of conciseness and structure.
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 (one parameter, no output schema, no annotations), the description is insufficient. It fails to explain the rotation process, the fate of the old key, or what the expected outcome is. A more complete description would clarify these aspects to guide the agent effectively.
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 documents the single parameter `key_id` with a clear description, and schema coverage is 100%. The tool description adds no extra semantic detail beyond what the schema already provides, but it is consistent with 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 uses a specific verb 'Rotate' with the resource 'API key', which clearly identifies the operation and distinguishes it from sibling tools like create_api_key, list_api_keys, and delete_api_key. However, the exact semantics of 'rotate' (e.g., invalidating the old key) are not explained, so it stops short of a 5.
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 usage guidance is provided. The description does not mention when to use rotation versus creating or deleting a key, nor does it state any prerequisites or contextual triggers. This leaves the agent without information on how to choose this tool appropriately.
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 implies a read-only operation via 'get', but does not explicitly state that it is non-destructive, whether authentication is required, or what kind of data is returned. No side effects, access limits, or error conditions are mentioned.
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, front-loaded sentence with no filler words. It is appropriately concise for a tool with no parameters. However, the extreme brevity contributes to under-specification, which prevents a higher score.
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 very simple (no parameters, no output schema, no annotations), but the description still leaves major gaps. It does not explain what the output will contain, how to interpret the result, or any typical use cases. Since there is no output schema, the description should compensate by describing the return value, and it fails to do so.
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?
The tool has zero parameters, so the schema covers everything (100%). With no parameters, the baseline is 4, and the description does not need to add parameter semantics. However, it also does not clarify what the tool returns, which is a separate completeness concern.
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 the specific verb 'get' with a clear resource ('organization information'), and it is distinct from sibling tools which focus on memories, API keys, projects, and config. However, the resource is vague—it does not specify what aspect of organization information is returned, such as members, settings, or billing.
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?
There is no guidance on when to use this tool versus alternatives. Sibling tools like get_config or get_auth_status might also provide organization-related details, but no exclusions or preferred contexts are mentioned. The description only states what it does, not why or when to choose it.
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 responsibility for disclosing behavioral traits. It mentions 'with vector embedding' as a useful detail but does not disclose any side effects, permissions, return values, or limitations. It leaves the tool's operational behavior largely unexplained.
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 waste. However, its brevity comes at the cost of missing important context, so it earns a 4 rather than a 5 for efficiency with some loss of 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?
The description is very short and omits essential context for a tool with no output schema and no annotations. It does not explain what a memory entry is, what the vector embedding is for, what the tool returns, or any required inputs beyond what the schema shows. This is inadequate for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, which is moderate, but the description adds no parameter information beyond what the schema already provides. It does not clarify ambiguous parameters like 'tags' or 'memory_type', and with moderate coverage the description should compensate more than it does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Create a new memory entry') and is clearly differentiated from sibling tools like search_memories, get_memory, update_memory, and delete_memory. It unambiguously states the tool's function.
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 creating memories) but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The sibling context makes the intended use clear, but there is no explicit guidance.
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 for behavioral disclosure. It simply states the action but does not mention irreversibility, permission requirements, or error behavior for non-existent IDs, which are important for a destructive 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?
The description is a single concise sentence with no unnecessary words. It is front-loaded with the core purpose and easily digestible.
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 one-parameter delete tool without annotations or output schema, the description is minimal. It fails to disclose whether the deletion is permanent, what the response looks like, or edge-case behavior, leaving significant gaps for an agent to operate safely.
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 already describes 'id' as 'Memory ID' with 100% coverage. The description restates 'by ID' but adds no meaningful semantic detail beyond what the schema provides, so the baseline score of 3 applies.
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 'Delete a memory by ID' clearly states the action (delete), the resource (memory), and the required parameter (ID). This distinguishes it from siblings like get_memory, update_memory, and list_memories.
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 does not mention when deletion is appropriate or any exclusions, leaving the agent to infer usage solely from the tool's name and description.
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 present, so the description carries the full burden of behavioral disclosure. It merely restates the tool's name ('Delete an API key') and does not disclose side effects, irreversibility, or security implications. This is minimal transparency for a destructive action.
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 is front-loaded and efficient.
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 delete operation with one documented parameter, the description is minimally sufficient. However, it lacks any context about the operation's effect (e.g., permanent deletion) or expected return value, which would be useful given there is no output schema.
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 the single parameter (key_id) with 100% coverage, so the description adds no additional parameter semantics. The baseline score of 3 applies because the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('API key'), clearly distinguishing it from sibling tools like create_api_key, list_api_keys, and rotate_api_key. It is unambiguous and direct.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it state any prerequisites or exclusions. For a destructive operation, some context about appropriate use would be helpful.
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 bears full responsibility for disclosing behavior. It only states the action, leaving out important details such as what happens if the ID is not found, whether the full memory object is returned, or any auth requirements. The description adds minimal transparency beyond the tool's 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, front-loaded sentence that directly communicates the tool's function without unnecessary words. 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 simple get-by-ID tool with one parameter and no output schema, the description is minimally adequate. However, it does not describe the return value or error behavior, which is relevant when no output schema is present. A more complete description might mention 'Returns the memory object' or 'Raises error if not found.'
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%, with the only parameter 'id' described as 'Memory ID'. The description repeats 'by ID' without adding further semantic detail, such as ID format, example values, or edge cases. This meets the baseline for fully documented schema parameters.
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 ('Get') and the specific resource ('a specific memory by ID'). It distinguishes this from siblings like list_memories (which retrieves multiple) and search_memories (which likely uses queries). The purpose is unmistakable.
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 implies that it is for fetching a single memory by ID, but it does not explicitly mention scenarios or contrast with list_memories or search_memories. No exclusions or alternative recommendations are given.
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. It only restates the tool's name and does not explain what data is returned, whether any side effects occur, or how 'health' is measured. This is minimal and leaves significant ambiguity for an agent.
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 with no wasted words. It is front-loaded and immediately clear in purpose, making it an example of concise, well-structured content.
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?
While the tool is simple with no parameters or output schema, the description does not explain what constitutes 'health status' or what the return format looks like. An agent would not know whether to expect metrics, booleans, or detailed reports. This lack of completion could lead to incorrect usage or interpretation.
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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning, but none is needed since the input schema is empty.
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 'Get system health status' clearly identifies the action (Get) and resource (system health status). It is unambiguous and distinguishes itself from all sibling tools, which focus on memories, API keys, and configuration.
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 when system health is needed, but provides no explicit guidance on when to use this tool versus alternatives. However, it is a unique tool among siblings with no obvious alternatives, so the lack of exclusion guidance is not a major gap.
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:

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

Score Badge

Copy to your README.md:

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

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/lanonasis/onasis-mcp-server'

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