RBT Document Editor

by leo7nel23

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have some clear distinctions (add_document vs. search operations), but there is notable overlap between delete_entity_edge and delete_episode (both delete operations on graph components) and between search_memory_facts and search_memory_nodes (both search operations with similar parameters). The descriptions help differentiate them, but an agent might occasionally misselect between these pairs.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern (e.g., add_document, clear_graph, delete_entity_edge, get_episodes, search_memory_facts). The naming is uniform across all eight tools, using snake_case throughout without any deviations or mixed conventions.
Tool Count4/5
With 8 tools, the count is reasonable for a document editor and graph memory management system. It covers core operations like adding documents, clearing data, deleting entities, retrieving information, and searching. However, it feels slightly thin for a full CRUD lifecycle, as there are no update tools for entities or episodes, but the scope is still well-defined.
Completeness3/5
The toolset covers key operations for document syncing and graph memory management, including add, delete, get, and search functions. However, there are notable gaps: no update tools for entities or episodes, and no create tools for entities or episodes independently (only via add_document). This could lead to dead ends when agents need to modify existing graph data without replacing entire documents.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 2.9/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 status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a deletion operation, implying it's destructive, but doesn't clarify if it's irreversible, requires specific permissions, affects related data, or has side effects like cascading deletions. The example and return statement add minimal context, leaving significant gaps 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 appropriately sized and front-loaded with the core purpose in the first sentence. Additional sections (Args, Returns, Example) are structured but include some redundancy (e.g., the example repeats the function call). The metadata tags (@REQ, @BP, @TASK) are extraneous for tool selection, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter with 0% schema coverage and an output schema (implied by 'Returns'), the description is moderately complete. It covers the basic operation and parameter intent but lacks details on behavioral traits, error handling, and usage context. For a destructive tool with no annotations, it should provide more guidance on safety and prerequisites to be fully adequate.
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 0%, so the schema provides no parameter details. The description adds basic semantics by explaining 'uuid' as 'UUID of the entity edge to delete', which clarifies its purpose. However, it doesn't specify format constraints (e.g., UUID version), validation rules, or where to obtain the UUID, resulting in incomplete compensation for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('entity edge from the graph memory'), making the purpose specific and understandable. It distinguishes from siblings like 'get_entity_edge' (read vs. delete) and 'clear_graph' (delete all vs. specific edge). However, it doesn't explicitly differentiate from 'delete_episode', which might be a related but different resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing the UUID from a prior operation), when not to use it (e.g., for bulk deletions), or direct comparisons to siblings like 'delete_episode' or 'clear_graph'. Usage is implied through the example but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes an episode, implying a destructive mutation, but doesn't cover critical aspects like whether deletion is permanent, requires specific permissions, has side effects on related graph elements, or handles invalid UUIDs. The mention of a 'Success message dictionary' return is minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement, parameter explanation, return note, and example. Every sentence adds value, and it's front-loaded with the core action. Minor trimming of meta-tags like '@REQ' could improve conciseness, but overall it's 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?
Given the tool's complexity (destructive operation with 1 parameter) and the presence of an output schema (which handles return values), the description is moderately complete. It covers the basic purpose and parameter semantics but lacks usage guidelines, detailed behavioral context (e.g., deletion permanence), and integration with sibling tools, leaving gaps for an AI agent.
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 significant value beyond the input schema, which has 0% description coverage. It explains that 'uuid' is the 'UUID of the episode to delete', clarifying the parameter's purpose and format, and provides an example with a sample UUID. This compensates well for the schema's lack of documentation, though it could elaborate on UUID format constraints.
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 ('Delete') and resource ('an episode from the graph memory'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'clear_graph' (which might delete all episodes) or 'delete_entity_edge' (which deletes different graph elements), so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention when to choose 'delete_episode' over 'clear_graph' for bulk deletion or how it relates to 'get_episodes' for verification. There's also no mention of prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'most recent memory episodes,' implying a read-only operation, but doesn't disclose other traits like authentication needs, rate limits, error handling, or what 'memory episodes' entail. The description lacks details on behavioral aspects beyond the basic function, leaving gaps for the 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 appropriately sized and front-loaded, starting with the core purpose, followed by parameter explanations, return value, and an example. Every sentence adds value without redundancy, and the structure is logical and efficient, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is fairly complete. It covers the purpose, parameters, and return value, and the output schema likely handles return details, reducing the need for more in the description. However, it lacks usage guidelines and some behavioral context, which holds it back from a perfect score.
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 significant meaning beyond the input schema, which has 0% description coverage. It explains that 'group_id' is for retrieving episodes from a specific group, with a default fallback, and 'last_n' specifies the number of most recent episodes to retrieve, including the default value. This compensates well for the schema's lack of descriptions, providing clear semantics for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the most recent memory episodes for a specific group.' It specifies the verb ('Get'), resource ('memory episodes'), and scope ('for a specific group'), which is clear and specific. However, it doesn't explicitly distinguish this tool from sibling tools like 'search_memory_facts' or 'search_memory_nodes', which might also retrieve memory-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions retrieving episodes for a group but doesn't compare it to sibling tools like 'search_memory_facts' or 'search_memory_nodes', which might serve similar purposes. There's no mention of prerequisites, exclusions, or specific contexts for usage, leaving the agent with little direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'returns' results but doesn't describe what happens during execution (e.g., search algorithm, performance characteristics, error conditions, or rate limits). For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns, example) and uses minimal, purposeful sentences. Every element adds value without redundancy, and the example provides concrete usage guidance efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, 1 required) and the presence of an output schema (which handles return value documentation), the description provides adequate context. The parameter semantics are well-covered, and the example adds practical guidance. The main gap is the lack of behavioral context and usage guidelines relative to siblings.
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 provides clear semantic explanations for all 4 parameters in the 'Args' section, adding meaningful context beyond the schema's 0% description coverage. Each parameter is explained with purpose and defaults where applicable, fully compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('search') and resource ('graph memory for relevant facts'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'search_memory_nodes', which appears to be a related search operation, so it doesn't achieve the highest score for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_memory_nodes' or other siblings. There's no mention of prerequisites, appropriate contexts, or exclusions, leaving the agent with minimal usage direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that results are filtered summaries of node relationships and includes an example, but lacks details on permissions, rate limits, error handling, or pagination. It adds some behavioral context (e.g., default max_nodes, entity filtering) but is incomplete for a search tool with multiple parameters.
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 well-structured with a clear opening sentence, explanatory note, parameter details, return statement, and example. It's appropriately sized without wasted sentences, though the entity filtering note is repeated in the parameter list, slightly reducing efficiency.
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 5 parameters with 0% schema coverage and no annotations, the description does a good job explaining parameters and includes an example. With an output schema present, it doesn't need to detail return values. However, it could better address usage context and behavioral aspects like error cases or performance expectations.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all parameters: explains 'query' as the search query, 'group_ids' for filtering, 'max_nodes' with default, 'center_node_uuid' for centering search, and 'entity' with permitted values. This goes beyond the schema's basic titles, though it could elaborate on parameter interactions.
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 searches for 'relevant node summaries' in 'graph memory' and specifies these summaries contain 'a summary of all of a node's relationships with other nodes.' This provides a specific verb ('search') and resource ('graph memory nodes'), though it doesn't explicitly differentiate from sibling tools like 'search_memory_facts' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_memory_facts' or other siblings. The description mentions filtering by entity types but doesn't explain when this filtering is appropriate or what distinguishes this search from other search tools in the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses this is a retrieval operation (non-destructive) and specifies the return format, but doesn't mention error handling (e.g., what happens if UUID doesn't exist), authentication needs, rate limits, or performance characteristics. It adds basic behavioral context but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: purpose statement first, followed by Args/Returns/Example sections. Every sentence adds value—no fluff. The example is minimal yet complete. The metadata tags (@REQ, @BP, @TASK) are extraneous but don't detract from core clarity.
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 1 parameter, no annotations, but with an output schema (implied by Returns section), the description is mostly complete. It covers purpose, parameter meaning, and return structure. However, for a read operation with no annotations, it could better address error cases or prerequisites (e.g., required permissions).
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?
Schema description coverage is 0%, so the description must compensate. It clearly explains the single parameter ('UUID of the entity edge to retrieve'), adding essential meaning beyond the schema's generic string type. However, it doesn't specify UUID format constraints (e.g., UUIDv4 pattern) or validation rules.
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 specific action ('Get an entity edge') and resource ('from the graph memory by its UUID'), distinguishing it from siblings like delete_entity_edge (destructive) or search_memory_facts (search-based). The verb 'retrieve' precisely indicates a read operation without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you know the exact UUID of an entity edge, but doesn't explicitly contrast with alternatives like search_memory_facts for unknown UUIDs or get_episodes for related data. It provides clear context (retrieval by UUID) but lacks explicit when-not-to-use guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: comparing files, chunking, identifying changes, and syncing differences. It also mentions error conditions (FileNotFoundError, ValueError) and includes examples, though it could elaborate more on side effects or performance implications.
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 well-structured with sections for purpose, arguments, returns, raises, and examples, making it easy to navigate. It is appropriately sized but includes some redundancy (e.g., repeating parameter details in examples). Every sentence adds value, though minor trimming could improve conciseness.
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 complexity (5 parameters, mutation operation) and no annotations, the description is highly complete. It covers purpose, parameters, return values (with output schema), error cases, and examples. The presence of an output schema reduces the need to explain returns in detail, and the description fills all other gaps effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides detailed semantics for all 5 parameters, including usage notes, examples, and distinctions between RBT and general documents. This adds significant value beyond the basic schema, fully documenting parameter meanings and constraints.
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 specific action: 'compare new file with ROOT original file and sync differences to Graphiti.' It explicitly mentions chunking both versions, identifying changes, and syncing to a knowledge graph, which distinguishes it from sibling tools that focus on deletion, retrieval, or search operations.
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 for usage through examples and parameter explanations, such as distinguishing between RBT and general documents. However, it does not explicitly state when to use this tool versus alternatives or mention any prerequisites beyond parameter requirements.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical behavioral traits: the irreversible destructive nature ('will delete all data'), the rebuild indices behavior, and the return format ('Success message dictionary'). This provides essential context beyond what the empty input schema offers.
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 well-structured with clear sections: purpose statement, warning, return information, and example. While the example and metadata tags (@REQ, @BP, @TASK) could be considered extraneous, the core description is appropriately sized and front-loaded with the most critical information.
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 this is a destructive operation with no annotations, the description provides complete context: purpose, irreversible nature, warning, return format, and example. The existence of an output schema means the description doesn't need to detail return values, and it appropriately focuses on behavioral implications.
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?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's behavior and consequences, which is the correct emphasis for a parameterless destructive operation.
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 specific action ('clear all data from the graph memory and rebuild indices'), identifies the resource ('graph memory'), and distinguishes this destructive operation from sibling tools that perform more targeted operations like add_document, delete_entity_edge, or search functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with a WARNING section stating 'Use with extreme caution' and noting the operation is irreversible. It clearly distinguishes this from other tools by emphasizing it deletes ALL data, unlike sibling tools that perform selective operations.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/leo7nel23/KnowledgeSmith-MCP'

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