jalipata-mcp-memory

Server Quality Checklist

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

Latest release: v0.1.5
Disambiguation5/5
Each tool targets a distinct operation: creating entities, creating relations, adding observations, and deleting each of those, plus distinct retrieval methods (read graph, search, open by name) and namespace listing. No two tools have overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (create_entities, delete_relations, open_nodes, etc.). The only slight variation is 'add_observations' versus 'create_*', but 'add' is still a clear active verb in the same style.
Tool Count5/5
With 10 tools, the server is well-scoped for a knowledge graph memory system. Each tool covers a essential operation without redundancy, and the count is within the ideal range for a focused server.
Completeness4/5
The surface covers the full CRUD lifecycle for entities, relations, and observations, plus retrieval and namespace listing. Minor gaps exist such as no update/rename operation for entities or relations, but these are not critical for typical memory graph workflows.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 55 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that entities with an existing name are ignored, which implies idempotent behavior (repeated calls with the same entities have no additional effect). However, the annotations set idempotentHint to false, directly contradicting this implication. Per the rubric, this is an annotation contradiction requiring a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. It front-loads the purpose and adds the key behavioral trait (ignoring existing names) without extraneous information. Every word earns its place.
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 batch creation tool, the description covers the core purpose and the most critical edge case (duplicate names). The schema provides details on parameters and the output schema exists (though not shown), so return values need not be described. However, the idempotency contradiction weakens overall completeness, and there is no mention of partial failures or namespace defaults, though those are partly addressed by schema.
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 input schema has 50% description coverage: the 'namespace' parameter is well-described, but the 'entities' array property lacks a top-level description. The tool description adds no further parameter semantics—it merely repeats the word 'entities' without explaining the structure or namespace behavior, leaving the agent to rely entirely on the incomplete schema.
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 creates multiple new entities in the knowledge graph, using a specific verb ('Create') and resource ('entities'). It is distinct from sibling tools like create_relations, which handle relations, and add_observations, which add observations to existing entities.
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 clearly implies this tool is for adding new entities, and the behavior of ignoring existing names is a useful context cue. It does not explicitly state alternatives or when-not-to-use, but the sibling tool names provide enough situational awareness for an agent to differentiate.
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?
The description contradicts the annotation openWorldHint=false by stating 'Missing endpoint entities are created automatically.' This is an open-world behavior, directly conflicting with the closed-world annotation. Therefore, score is 1 per contradiction rule.
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 three concise sentences, each adding distinct value: main purpose, formatting rule, and auto-creation behavior. No redundant information; it's front-loaded with the primary action.
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 description covers the main usage and key behavior (auto-creation). An output schema exists, so return values are presumably defined. However, the contradiction with openWorldHint could confuse an agent; also, edge cases like partial failures are not addressed. But given the moderate complexity, it's mostly complete.
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 description adds meaning beyond the schema: 'Relations should be in active voice' specifies the format for relationType, and 'Missing endpoint entities are created automatically' clarifies that from and to can reference non-existent entities, which will be created. This complements the 50% 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: 'Create multiple new relations between entities.' This distinguishes it from sibling tools like create_entities (creates entities) and delete_relations (deletes relations). The additional details about active voice and automatic endpoint creation further clarify behavior.
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 clear context: it is for creating multiple relations, with guidance that relations should be in active voice. It does not explicitly mention alternatives or when-not-to-use, but the naming and sibling set make the purpose clear. The lack of explicit exclusion is acceptable given the straightforward domain.
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?
Annotations already indicate destructive and idempotent hints, but the description adds the valuable behavioral detail that the operation is 'Silent if a relation does not exist', which clarifies the idempotent nature and avoids unexpected errors. It also clarifies the scope (knowledge graph) and specificity of deletion. No contradiction with annotations, and it enriches the annotation data with contextual 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 only two sentences, immediately stating the purpose in the first sentence and adding a key behavioral nuance in the second. Every word earns its place, with no redundant content. It is front-loaded with the verb and object, making it highly scannable.
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 presence of an output schema and annotations, the description covers essential aspects: what it deletes, the silent behavior for missing relations, and the knowledge graph context. It doesn't mention namespace defaulting, but that's in the schema. It lacks an explicit note on when to use this vs. sibling delete tools, but the description is otherwise complete for a delete operation with good schema/annotation support.
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 rich descriptions for the namespace and the subfields of relations, but the top-level relations parameter lacks a direct description. The tool description adds minimal parameter insight beyond naming 'specific relations'. Overall, the schema carries most weight, and the description doesn't significantly compensate for the 50% coverage gap, though the subfields are well-documented.
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 verb 'Delete' and the resource 'specific relations from the knowledge graph', which precisely identifies the tool's purpose. It also distinguishes it from sibling tools like delete_entities and delete_observations by explicitly targeting relations. The mention of 'specific' relations adds clarity that it deletes user-selected edges, not all relations.
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 deleting particular relations by saying 'specific relations', and the tool name reinforces this. However, it does not explicitly state when to use this tool over alternatives (e.g., delete_entities, delete_observations) or provide exclusions. The guidance is inferred rather than explicit, so it falls short of a clear context for selection.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context by specifying what data is searched (entity names, types, observations) and what is returned (entities and connected relations), which goes beyond the structured annotations.
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 action ('Keyword search') and resource ('nodes in the knowledge graph'), followed by match criteria and return value. Every word added value, with no redundancy or fluff.
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 output schema exists (though not shown in the prompt), the description need not detail return format. The tool is a simple read-only search with well-annotated semantics and schema-complete parameters. Minor gaps like pagination or exact matching behavior are acceptable because annotations and schema cover safety and parameter details.
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% for both parameters (query and namespace). The description mirrors some of the query parameter semantics but does not add additional meaning beyond the schema's own descriptions. Baseline score of 3 is appropriate since the schema fully documents the 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 tool performs a keyword search over nodes in a knowledge graph, matching by entity names, types, and observations, and returns entities with connected relations. This distinguishes it from sibling tools like read_graph (full graph dump) and open_nodes (likely direct access) by emphasizing the search use case.
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 the tool is for searching nodes, but it does not explicitly state when to use it vs. alternatives like read_graph or open_nodes. No exclusion criteria or alternative tool references are provided, so the usage context is clear but not explicit about trade-offs.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it reads the 'entire' graph including all entities and relations, which is useful scope context. However, it does not disclose pagination, size limits, or behavior for missing namespaces, though these are partially mitigated by the output schema.
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, front-loaded with the verb 'Read', and contains no filler or redundant information. Every word contributes to understanding the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter, full schema coverage, an output schema, and comprehensive safety annotations, the description plus structured fields provide all necessary context. There are no missing prerequisites or side effects to explain.
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 provides 100% coverage for the single 'namespace' parameter with a detailed description including examples and default value. The tool description adds no additional parameter semantics, 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 uses the specific verb 'Read' and clearly identifies the resource as 'the entire knowledge graph for a namespace, including all entities and relations.' This distinguishes it from sibling tools like search_nodes (filtered search) and create_entities (write operation), making its purpose 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 clearly implies when to use this tool: when you need the complete knowledge graph for a namespace, not just a subset. However, it does not explicitly mention alternatives or when not to use it, stopping short of a 5.
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?
Annotations already indicate it's a write operation and non-idempotent; the description adds the crucial failure behavior when the entity does not exist and clarifies that observations are atomic facts. This goes beyond what the annotations convey about side effects.
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 entire description is a single 19-word sentence that front-loads the primary action and includes a key constraint. No redundant phrases or filler; every word earns its place.
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 write operation with annotations and a schema, the description provides the essential context: purpose, target, and a crucial error condition. It doesn't discuss return values, but the presence of an output schema covers that, and behavioral annotations handle idempotency and safety.
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 schema documents the namespace, entityName, and contents parameters with descriptions, but the top-level observations property lacks a description. The tool description compensates by explaining observations as atomic facts and emphasizing that entityName must refer to an existing entity, adding semantic meaning to the 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 identifies the action (add), the resource (observations as atomic facts), and the target (existing entities in the knowledge graph). It distinguishes itself from sibling tools like create_entities and create_relations by specifying the verb-noun combination and the constraint that entities must exist.
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 context, such as the need for entities to already exist, but does not explicitly state when to use this tool versus alternatives like create_entities or delete_observations. The failure condition suggests a prerequisite but no direct comparison to siblings.
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?
The description adds concrete behavioral detail beyond the annotations: 'Silent if an observation does not exist' expands on the idempotentHint and clarifies the tool's no-op behavior. It does not contradict any annotations and adds useful context 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 two short sentences, front-loaded with the action and resource, with no redundant filler. Every sentence adds value, including the behavioral note about silence.
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 destructive annotation, the presence of an output schema, and sibling tools, the description is mostly complete. It explains the core operation and the key edge case of missing observations, though it does not address behavior when the entity itself is missing, which would be useful but is not critical given the tool's focused purpose.
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 covers the namespace parameter in detail and the deletions array structure via nested property descriptions. The tool description adds some meaning with 'specific observations' but does not meaningfully compensate for the 50% schema description coverage at the top level; the deletions parameter lacks an explicit top-level description.
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 ('specific observations from entities in the knowledge graph'), clearly distinguishing it from sibling tools like delete_entities, delete_relations, and add_observations.
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 clearly states the tool's scope (deleting observations from entities), which implies when it should be used versus sibling tools. It does not explicitly mention alternatives or exclusions, but the focused wording provides enough context for selection.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the 'all' and 'scopes' context but does not disclose any further behavior such as pagination, ordering, or result limits. With strong annotations, this is adequate but not exceptional.
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 states the action and target concisely. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (no parameters, read-only, safe), the description, combined with strong annotations and an output schema, provides complete context. It clearly defines what the tool does without needing to explain return details that the output schema covers.
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 accepts zero parameters, which makes the input schema fully self-explanatory (100% coverage by construction). The description adds no parameter-specific meaning, but the baseline of 4 is appropriate for parameterless tools.
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 names the resource 'all memory namespaces (scopes)', clearly distinguishing it from sibling tools that focus on entities, relations, and observations. The parenthetical clarifies the meaning of namespaces.
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 clearly implies when to use this tool: when you need to enumerate available memory scopes. It does not explicitly name alternatives or exclusions, but no sibling tool serves this purpose, so the context is clear without needing contrast.
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?
Annotations already declare the operation read-only and idempotent; the description adds valuable context by disclosing that non-existent nodes are silently skipped, which is not captured in the annotations. This informs the agent about error handling without contradicting the structured metadata.
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 short sentences: the first states the core action and output scope, the second discloses a key behavioral nuance. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool with comprehensive schema annotations and an output schema, the description covers the essential purpose and the one non-obvious behavior (silent skipping). No further context is needed.
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?
Both parameters have thorough descriptions in the input schema (names and namespace with examples), covering 100% of parameters. The tool description adds no additional parameter-level meaning, so it earns the baseline 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 uses the specific verb 'Retrieve' with the resource 'specific nodes by name' and adds 'along with relations connected to them,' clearly distinguishing this from sibling tools like search_nodes (search by query) and read_graph (read entire graph).
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 clearly implies the tool is for retrieving nodes when their names are known ('specific nodes by name'), providing a distinct use case. However, it does not explicitly mention alternatives or exclusions, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it discloses the cascading deletion of relations and observations, and the silent behavior when an entity doesn't exist. These details are not present in the annotations (destructiveHint, idempotentHint) and are valuable for an agent. No contradiction with annotations.
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 short sentences, front-loaded with the core action ('Delete entities...') and no filler. The cascade and silent behavior are concise additions that earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and clear annotations, the description adequately covers the tool's behavior (cascading deletion, silent idempotency). It doesn't need to explain return values because an output schema exists, and the description is complete for an agent to understand when and how to use this 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 parameters are fully described in the schema. The description adds no additional parameter-level detail beyond what the schema already provides (e.g., format, defaults). 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes entities with a cascading effect on associated relations and observations, using specific verbs ('Delete') and the resource ('entities'). It also distinguishes itself from sibling tools like delete_relations and delete_observations by explicitly mentioning the cascading scope.
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 makes the use case clear: use this when you want to delete an entity and all its associated data. It implicitly contrasts with sibling tools (e.g., delete_relations for relations only), though it doesn't explicitly say 'use delete_relations instead when you only want to delete relations.' This is a minor 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:

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

Score Badge

Copy to your README.md:

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

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/alfianyusufabdullah/jalipata'

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