SourceSage는 코드베이스의 핵심 요소(논리, 스타일, 표준)를 효율적으로 기억하는 동시에 동적 업데이트와 빠른 검색을 지원하는 MCP(Model Context Protocol) 서버입니다. 언어에 구애받지 않고 LLM이 여러 언어의 코드를 이해하는 방식을 활용하도록 설계되었습니다.
언어 무관 : LLM이 이해하는 모든 프로그래밍 언어로 작업 가능
지식 그래프 저장소 : 코드 엔터티, 관계, 패턴 및 스타일 규칙을 효율적으로 저장합니다.
LLM 기반 분석 : LLM을 사용하여 코드를 분석하고 통찰력을 제공합니다.
토큰 효율적 스토리지 : 메모리 용량을 최대화하면서 토큰 사용량을 최소화하도록 최적화합니다.
증분 업데이트 : 중복 저장소 없이 코드가 변경될 때 지식을 업데이트합니다.
빠른 검색 : 관련 정보를 빠르고 정확하게 검색할 수 있습니다.
Related MCP server: Logseq MCP Tools
SourceSage는 다음과 같은 새로운 접근 방식을 사용합니다.
LLM은 코드 파일(모든 언어)을 분석합니다.
LLM은 MCP 도구를 사용하여 엔터티, 관계, 패턴 및 스타일 규칙을 등록합니다.
SourceSage는 이 지식을 토큰 효율적인 그래프 구조로 저장합니다.
LLM은 나중에 필요할 때 이 지식을 쿼리할 수 있습니다.
이 접근 방식은 MCP 서버의 효율적인 메모리 관리에 집중하는 동시에 LLM의 고유한 언어 이해력을 활용합니다.
지엑스피1
# Run the server
sourcesage
# Or run directly from the repository
python -m sourcesage.mcp_server데스크톱용 Open Claude
설정 > 개발자 > 구성 편집으로 이동하세요.
claude_desktop_config.json 에 다음을 추가하세요.
패키지를 설치한 경우:
{
"mcpServers": {
"sourcesage": {
"command": "sourcesage",
"args": []
}
}
}설치하지 않고 로컬 디렉토리에서 실행하는 경우:
{
"sourcesage": {
"command": "uv",
"args": [
"--directory",
"/path/to/sourcesage",
"run",
"main.py"
]
},
}데스크톱용 Claude를 다시 시작하세요
SourceSage는 다음과 같은 MCP 도구를 제공합니다.
register_entity : 지식 그래프에 코드 엔터티를 등록합니다.
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 : 엔티티 간 관계를 등록합니다.
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 : 코드 패턴을 등록합니다
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 : 코딩 스타일 규칙을 등록합니다.
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 : 엔티티에 관찰을 추가합니다.
Input:
- entity_name: Name of the entity
- observation: Observation to add
Output: Confirmation messagequery_entities : 지식 그래프의 쿼리 엔터티
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 : 엔터티에 대한 자세한 정보를 가져옵니다.
Input:
- entity_name: Name of the entity
Output: Detailed information about the entityquery_patterns : 지식 그래프의 쿼리 코드 패턴
Input:
- language: Filter by programming language (optional)
- pattern_name: Filter by pattern name (optional)
Output: List of matching patternsquery_style_conventions : 쿼리 코딩 스타일 규칙
Input:
- language: Filter by programming language (optional)
- convention_name: Filter by convention name (optional)
Output: List of matching style conventionsget_knowledge_statistics : 지식 그래프에 대한 통계를 가져옵니다.
Input: None
Output: Statistics about the knowledge graphclear_knowledge : 그래프에서 모든 지식을 지웁니다.
Input: None
Output: Confirmation message코드 분석 : Claude에게 코드 파일을 분석해 달라고 요청하세요.
"Please analyze this Python file and register the key entities and relationships."엔터티 등록 : Claude는 register_entity 도구를 사용하여 코드 엔터티를 저장합니다.
"I'll register the main class in this file."관계 등록 : Claude는 register_relationship 도구를 사용하여 관계를 저장합니다.
"I'll register the inheritance relationship between these classes."지식 쿼리 : 나중에 Claude에게 코드베이스에 대해 물어보세요.
"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?"코딩 패턴 얻기 : Claude에게 코딩 패턴에 대해 물어보세요
"What design patterns are used in my codebase?"
"Show me examples of the Factory pattern in my code."기존 코드 분석 도구와 달리 SourceSage는 다음과 같은 기능을 제공합니다.
LLM 이해 활용 : LLM의 기능을 활용하여 여러 언어의 코드 의미를 이해합니다.
의미 지식을 저장합니다 . 구문뿐만 아니라 의미와 관계에 초점을 맞춥니다.
언어에 구애받지 않음 : LLM이 이해하는 모든 프로그래밍 언어와 호환 가능
토큰 효율성을 최적화합니다 . 토큰 사용량을 최소화하는 방식으로 지식을 저장합니다.
LLM 역량 향상에 따른 진화 : LLM이 향상됨에 따라 코드 이해도 향상됩니다.
기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
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 |
|---|---|---|---|
| include_observations | No | ||
| project_path | Yes |
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 | ||
| limit | No | ||
| name_pattern | 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 |
|---|---|---|---|
| convention_name | No | ||
| language | 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 |
|---|---|---|---|
| entity_type | Yes | ||
| language | No | ||
| metadata | No | ||
| name | Yes | ||
| observations | No | ||
| signature | No | ||
| summary | Yes |
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 |
|---|---|---|---|
| description | Yes | ||
| example | No | ||
| language | No | ||
| metadata | No | ||
| name | Yes |
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 | ||
| metadata | No | ||
| relationship_type | Yes | ||
| to_entity | Yes |
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 |
|---|---|---|---|
| description | Yes | ||
| examples | No | ||
| language | No | ||
| metadata | No | ||
| name | Yes |
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.
v1.0.0add_entity_observationclear_knowledgedump_project_understandingget_entity_detailsget_knowledge_statisticsload_project_understandingquery_entitiesquery_patternsquery_style_conventionsregister_entityregister_patternregister_relationshipregister_style_conventionScored across 13 tools
Most tools have distinct purposes focused on different aspects of knowledge graph management (entities, patterns, relationships, style conventions). However, there is some potential overlap between dump_project_understanding and load_project_understanding as both handle project-level data, though their descriptions clarify one is for output and the other for input.
All tools follow a consistent snake_case naming pattern with clear verb_noun structure (e.g., add_entity_observation, get_entity_details, query_entities, register_entity). The naming is predictable and uniform across all 13 tools.
With 13 tools, this is well-scoped for a knowledge graph server covering entities, patterns, relationships, and style conventions. Each tool serves a specific function in the CRUD/lifecycle operations, and none appear redundant or out of place.
The toolset provides comprehensive coverage for managing a knowledge graph, including registration, querying, and statistics. Minor gaps exist, such as no explicit update or delete operations for entities/patterns/relationships/conventions, but agents can work around this by re-registering or using clear_knowledge.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Give your AI agent persistent, governed memory for every project. At task start it recalls the approved decisions, conventions, risks and architecture (semantic search, ranked by importance); at close it proposes what was learned as typed memories that you review and approve — governance, not a notes dump. Agents propose, humans govern: edits go back to pending and deletion is human-only by design. Connect Claude Code, Cursor, Claude Desktop or any MCP client in two minutes with just your API key — hosted (nothing to install) or locally via `uvx solucortex-mcp`. Built by SoluAI and dogfooded daily: SoluCortex is developed using its own living memory.
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
An MCP memory server. One memory your agents share — across models, devices and apps.
