Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sourcesage memorize the key entities and patterns of my project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
SourceSage is an MCP (Model Context Protocol) server that efficiently memorizes key aspects of a codebase—logic, style, and standards—while allowing dynamic updates and fast retrieval. It's designed to be language-agnostic, leveraging the LLM's understanding of code across multiple languages.
Language Agnostic: Works with any programming language the LLM understands
Knowledge Graph Storage: Efficiently stores code entities, relationships, patterns, and style conventions
LLM-Driven Analysis: Relies on the LLM to analyze code and provide insights
Token-Efficient Storage: Optimizes for minimal token usage while maximizing memory capacity
Incremental Updates: Updates knowledge when code changes without redundant storage
Fast Retrieval: Enables quick and accurate retrieval of relevant information
Related MCP server: Axon.MCP.Server
SourceSage uses a novel approach where:
The LLM analyzes code files (in any language)
The LLM uses MCP tools to register entities, relationships, patterns, and style conventions
SourceSage stores this knowledge in a token-efficient graph structure
The LLM can later query this knowledge when needed
This approach leverages the LLM's inherent language understanding while focusing the MCP server on efficient memory management.
# Clone the repository
git clone https://github.com/yourusername/sourcesage.git
cd sourcesage
# Install the package
pip install -e .# Run the server
sourcesage
# Or run directly from the repository
python -m sourcesage.mcp_serverOpen Claude for Desktop
Go to Settings > Developer > Edit Config
Add the following to your claude_desktop_config.json:
If you've installed the package:
{
"mcpServers": {
"sourcesage": {
"command": "sourcesage",
"args": []
}
}
}If you're running from a local directory without installing:
{
"sourcesage": {
"command": "uv",
"args": [
"--directory",
"/path/to/sourcesage",
"run",
"main.py"
]
},
}Restart Claude for Desktop
SourceSage provides the following MCP tools:
register_entity: Register a code entity in the knowledge graph
Input:
- name: Name of the entity (e.g., class name, function name)
- entity_type: Type of entity (class, function, module, etc.)
- summary: Brief description of the entity
- signature: Entity signature (optional)
- language: Programming language (optional)
- observations: List of observations about the entity (optional)
- metadata: Additional metadata (optional)
Output: Confirmation message with entity IDregister_relationship: Register a relationship between entities
Input:
- from_entity: Name of the source entity
- to_entity: Name of the target entity
- relationship_type: Type of relationship (calls, inherits, imports, etc.)
- metadata: Additional metadata (optional)
Output: Confirmation message with relationship IDregister_pattern: Register a code pattern
Input:
- name: Name of the pattern
- description: Description of the pattern
- language: Programming language (optional)
- example: Example code demonstrating the pattern (optional)
- metadata: Additional metadata (optional)
Output: Confirmation message with pattern IDregister_style_convention: Register a coding style convention
Input:
- name: Name of the convention
- description: Description of the convention
- language: Programming language (optional)
- examples: Example code snippets demonstrating the convention (optional)
- metadata: Additional metadata (optional)
Output: Confirmation message with convention IDadd_entity_observation: Add an observation to an entity
Input:
- entity_name: Name of the entity
- observation: Observation to add
Output: Confirmation messagequery_entities: Query entities in the knowledge graph
Input:
- entity_type: Filter by entity type (optional)
- language: Filter by programming language (optional)
- name_pattern: Filter by name pattern (regex, optional)
- limit: Maximum number of results to return (optional)
Output: List of matching entitiesget_entity_details: Get detailed information about an entity
Input:
- entity_name: Name of the entity
Output: Detailed information about the entityquery_patterns: Query code patterns in the knowledge graph
Input:
- language: Filter by programming language (optional)
- pattern_name: Filter by pattern name (optional)
Output: List of matching patternsquery_style_conventions: Query coding style conventions
Input:
- language: Filter by programming language (optional)
- convention_name: Filter by convention name (optional)
Output: List of matching style conventionsget_knowledge_statistics: Get statistics about the knowledge graph
Input: None
Output: Statistics about the knowledge graphclear_knowledge: Clear all knowledge from the graph
Input: None
Output: Confirmation messageAnalyze Code: Ask Claude to analyze your code files
"Please analyze this Python file and register the key entities and relationships."Register Entities: Claude will use the register_entity tool to store code entities
"I'll register the main class in this file."Register Relationships: Claude will use the register_relationship tool to store relationships
"I'll register the inheritance relationship between these classes."Query Knowledge: Later, ask Claude about your codebase
"What classes are defined in my codebase?"
"Show me the details of the User class."
"What's the relationship between the User and Profile classes?"Get Coding Patterns: Ask Claude about coding patterns
"What design patterns are used in my codebase?"
"Show me examples of the Factory pattern in my code."Unlike traditional code analysis tools, SourceSage:
Leverages LLM Understanding: Uses the LLM's ability to understand code semantics across languages
Stores Semantic Knowledge: Focuses on meaning and relationships, not just syntax
Is Language Agnostic: Works with any programming language the LLM understands
Optimizes for Token Efficiency: Stores knowledge in a way that minimizes token usage
Evolves with LLM Capabilities: As LLMs improve, so does code understanding
Contributions are welcome! Please feel free to submit a Pull Request.
This project is licensed under the MIT License - see the LICENSE file for details.
Add an observation to an entity.
Args: entity_name: Name of the entity observation: Observation to add
| Name | Required | Description | Default |
|---|---|---|---|
| entity_name | Yes | ||
| observation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and minimal description. Does not disclose whether observations are appended, overwritten, or require entity existence. Lacks behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very brief, but lacks depth. Concise but under-specified for a mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no mention of return values or side effects. Incomplete for understanding the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description only restates parameter names and types from the schema without adding meaning (e.g., format or constraints).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'add' and the resource 'observation to an entity', distinguishing it from siblings like register_entity or get_entity_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No mention of prerequisites (e.g., entity must exist) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all knowledge from the graph.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 destructive operation (clearing all data), but lacks details on irreversibility, permissions, or side effects. The minimal description is adequate for a simple tool but could be more informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and easily digestible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description completely conveys the tool's purpose. The term 'graph' is likely understood from context, and no further elaboration is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per guidelines the baseline is 4. The description adds no parameter information because none exist; it is consistent with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: clearing all knowledge from the graph. The verb 'Clear' and resource 'all knowledge from the graph' are specific and distinguish it from sibling tools like add_entity_observation or query_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 any prerequisites, consequences, or situations where clearing knowledge is appropriate, 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.
Dump understanding of an entire project at once.
This tool provides a comprehensive dump of all knowledge related to a project, including all entities, relationships, patterns, and style conventions.
Args: project_path: Path to the project root directory include_observations: Whether to include detailed observations
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| include_observations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool provides a 'comprehensive dump' but does not specify read-only nature, potential performance costs, or output format. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the main action and uses a clear bullet list for parameters. It is concise with no redundant sentences, though could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 omits return format and side effects. For a dump tool, the minimal info is present, but a user might benefit from more details on output structure or impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's Args section adds needed meaning: 'project_path: Path to the project root directory' and 'include_observations: Whether to include detailed observations'. This clarifies purpose but lacks further detail like allowed values or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it dumps entire project understanding, listing included components (entities, relationships, patterns, style conventions). This differentiates it from sibling tools that focus on specific aspects or individual queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for comprehensive project knowledge but does not explicitly state when to use this tool over alternatives like query_entities or load_project_understanding. No exclusion criteria or comparative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about an entity.
Args: entity_name: Name of the entity
| Name | Required | Description | Default |
|---|---|---|---|
| entity_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits like whether it is read-only, error handling (e.g., if entity doesn't exist), or any side effects. The agent cannot infer important behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified, not concise. It consists of a single sentence and a parameter line that adds negligible value. Every sentence should earn its place, but here it fails to provide necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a single parameter, the description must cover return format, error conditions, and prerequisites. It does none of these, making it incomplete for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description restates the parameter name ('Name of the entity') with minimal added meaning beyond the schema. Schema description coverage is 0%, so the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('get') and resource ('detailed information about an entity'), distinguishing it from siblings like 'register_entity' which creates entities. However, it does not explicitly differentiate from other query tools like 'query_entities'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'query_entities' or 'dump_project_understanding'. It lacks any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics about the knowledge graph.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It only states the action with no mention of side effects, auth requirements, or what 'statistics' entails. Minimal information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it lacks detail necessary for adequate understanding. Every sentence should earn its place, and while not verbose, it is under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters or output schema, but the description fails to explain what statistics are returned, how to use them, or any context. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so baseline is 3 per rules. The description does not add any parameter meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get statistics about the knowledge graph' clearly states the verb and resource, distinguishing it from siblings that focus on specific entities, patterns, or relationships. However, it does not specify which statistics are provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 query_patterns or get_entity_details. No context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load understanding of an entire project at once.
This tool should be used by MCP clients to quickly get project understanding if available, instead of reading all the files individually. It loads all entities, relationships, patterns, and style conventions related to the project.
Args: project_path: Path to the project root directory
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the tool as loading data (likely read-only) but does not confirm side effects, caching, or network dependencies. The behavioral information is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with an actionable first sentence. However, it includes a redundant 'Args:' section that mirrors the schema, taking unnecessary space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the return structure or format. It only lists what is loaded but not how it is presented. Additionally, it does not differentiate from the sibling 'dump_project_understanding', leaving the agent without full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'project_path' is described as 'Path to the project root directory', which adds no meaning beyond the input schema's title. With 0% schema description coverage, the description should provide more context, such as format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it loads project understanding including entities, relationships, patterns, and style conventions, distinguishing it from reading files individually. However, it does not differentiate from the sibling tool 'dump_project_understanding', which likely has a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool instead of reading all files individually, providing clear context for when to use it. It does not, however, list exclusions or alternatives beyond reading files, such as the sibling 'dump_project_understanding'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query entities in the knowledge graph.
Args: entity_type: Filter by entity type (class, function, module, etc.) language: Filter by programming language name_pattern: Filter by name pattern (regex) limit: Maximum number of results to return
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | No | ||
| language | No | ||
| name_pattern | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as side effects, read-only status, pagination, or output format. It only describes filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a structured list format for parameters with no superfluous text. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotation context. The description fails to explain what the tool returns, any sorting or pagination, or edge case behavior, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful semantics by explaining each parameter (entity type, language, regex pattern, limit). However, it lacks examples or further detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Query entities in the knowledge graph', which is a clear verb-resource pair. It distinguishes from sibling query tools like query_patterns and query_style_conventions by specifying entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only lists parameters without any context about use cases, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query code patterns in the knowledge graph.
Args: language: Filter by programming language pattern_name: Filter by pattern name
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ||
| pattern_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Query', implying a read operation, but lacks detail on performance, side effects, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for the tool purpose, then two lines for parameters. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or behavioral annotations, the description omits return format, filtering behavior, and other contextual details needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful explanations for both parameters ('Filter by programming language', 'Filter by pattern name'), compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries code patterns in the knowledge graph, distinguishing it from siblings like query_entities. The verb 'Query' and resource 'code patterns' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like query_entities. The description merely states what it does without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query coding style conventions in the knowledge graph.
Args: language: Filter by programming language convention_name: Filter by convention name
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ||
| convention_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool queries conventions but does not disclose behaviors like read-only nature, potential limits, or side effects. The description is too minimal to provide adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence to state the purpose and two lines for parameter explanations. No unnecessary words or repetition, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with two optional parameters and no output schema, the description covers the basic purpose and filter options but omits what the return data looks like or any default behavior. Some context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for parameters (0% coverage), but the description adds 'Filter by' semantics for both 'language' and 'convention_name'. This provides functional meaning beyond type definitions, though it could be more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query coding style conventions in the knowledge graph', specifying the action (query) and resource (coding style conventions). It distinguishes itself from sibling tools like query_entities and query_patterns by targeting a specific resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 query_entities or query_patterns. It does not mention prerequisites or context for usage, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a code entity in the knowledge graph.
Args: name: Name of the entity (e.g., class name, function name) entity_type: Type of entity (class, function, module, etc.) summary: Brief description of the entity signature: Entity signature (e.g., function signature) language: Programming language observations: List of observations about the entity metadata: Additional metadata as key-value pairs
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| entity_type | Yes | ||
| summary | Yes | ||
| signature | No | ||
| language | No | ||
| observations | No | ||
| metadata | No |
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 the registration action without detailing idempotency, error conditions (e.g., duplicate entry), or side effects. The parameter list does not address behavioral traits beyond input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded purpose. The argument list is necessary due to missing schema descriptions. No wasted words, though the structure could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (3 required), no output schema, and no annotations, the description covers the input fields adequately. However, it omits details on return values, error handling, and behavior on duplicates, leaving some gaps for a registration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes a docstring-style list of each parameter with brief explanations (e.g., 'name: Name of the entity'). This adds meaning beyond the bare schema titles, though it lacks examples or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the verb 'Register' and the resource 'code entity' in the 'knowledge graph'. It distinguishes from sibling tools like 'register_pattern' and 'register_relationship' by specifying it's for code entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when adding a new entity to the knowledge graph, but provides no explicit guidance on when to use this vs alternatives like 'query_entities' or 'get_entity_details'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a code pattern.
Args: name: Name of the pattern description: Description of the pattern language: Programming language example: Example code demonstrating the pattern metadata: Additional metadata as key-value pairs
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | Yes | ||
| language | No | ||
| example | No | ||
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions registration but does not disclose side effects (e.g., persistence, overwriting behavior, validation) or state changes beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a short introductory line followed by a structured Args list. It avoids unnecessary text but could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 5 parameters, no output schema, and no annotations, the description covers the basic function and parameter meanings but lacks usage guidelines and behavioral transparency. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides a labeled list with brief explanations for each parameter (e.g., 'name: Name of the pattern'). This adds semantic meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Register a code pattern' which clearly indicates the tool creates/registers a pattern. However, it does not differentiate from sibling tools like 'register_entity' or 'register_style_convention', but the purpose is clear and specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., query_patterns, register_entity). The description lacks any context about prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a relationship between entities.
Args: from_entity: Name of the source entity to_entity: Name of the target entity relationship_type: Type of relationship (calls, inherits, imports, etc.) metadata: Additional metadata as key-value pairs
| Name | Required | Description | Default |
|---|---|---|---|
| from_entity | Yes | ||
| to_entity | Yes | ||
| relationship_type | Yes | ||
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits such as idempotency, validation, or side effects. It only repeats the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose line, but the structure includes a docstring-style 'Args' section that lists parameters without adding value. It could be more concise by focusing on core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is insufficient. It lacks details about return values, error handling, or behavior on duplicate relationships.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter descriptions add no meaningful information beyond parameter names; e.g., 'from_entity: Name of the source entity' is tautological. No constraints, examples, or allowed values are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Register a relationship between entities' clearly defines the action and resource. It distinguishes from siblings like 'register_entity' by specifying 'relationship between entities'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any prerequisites or contextual conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a coding style convention.
Args: name: Name of the convention description: Description of the convention language: Programming language examples: Example code snippets demonstrating the convention metadata: Additional metadata as key-value pairs
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | Yes | ||
| language | No | ||
| examples | No | ||
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the tool overwrites existing conventions, side effects, persistence, authorization needs, or return behavior. 'Register' implies creation but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but the Args list repeats information already clear from the parameter names and required status. It could be more compact by removing redundant individual descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description fails to explain return values, error conditions, or side effects. It is insufficient for an agent to use confidently without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description's parameter explanations (e.g., 'Name of the convention') are trivial and add no meaning beyond the parameter names in the schema. They do not provide types, constraints, formats, or usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Register a coding style convention' with a specific verb and resource. However, it does not explicitly differentiate from sibling registration tools like register_entity or register_pattern beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives (e.g., register_entity, query_style_conventions). It does not mention prerequisites, exclusions, or that query_style_conventions is for retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_entity_observationclear_knowledgedump_project_understandingget_entity_detailsget_knowledge_statisticsload_project_understandingquery_entitiesquery_patternsquery_style_conventionsregister_entityregister_patternregister_relationshipregister_style_conventionEach tool has a clearly distinct purpose. Query, register, and utility tools are well-separated; even similar verbs like 'dump' and 'load' target different operations (output vs input). No overlapping functionality.
All tool names follow a consistent verb_noun pattern using snake_case. Verbs like register, query, get, add, clear, dump, load are distinct and predictable. Nouns clearly indicate the resource.
13 tools is well within the ideal range for a domain-specific knowledge graph server. The number covers core operations without being excessive, and each tool serves a specific purpose.
Missing update and delete operations for entities, patterns, relationships, and style conventions. Also lacks a dedicated query for relationships and a way to list all entities without filtering. These gaps can cause agent failures when needing to modify or remove specific data.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
An MCP server that gives your AI access to the source code and docs of all public github repos
An MCP memory server. One memory your agents share — across models, devices and apps.
A MCP server built for developers enabling Git based project management with project and personal…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mcpflow/sourcesage'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
