rawthink

by ygtalp

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v2.0.1
Disambiguation2/5
Multiple tools have overlapping purposes: record overlaps with create_entities, create_relations, and add_observations as a 'single write path,' and revise and invalidate_observations both mark observations as invalidated with optional supersession info. These unclear boundaries will lead to agent misselection.
Naming Consistency4/5
Most tools follow a clear verb_noun snake_case pattern (e.g., search_thoughts, create_entities, delete_relations), but a few use bare verbs (reindex, record, revise) that break the pattern. The overall convention is readable and predictable with only minor deviations.
Tool Count4/5
With 17 tools, the count is slightly above the typical 3-15 range, but it is justified by the server's dual focus on vault/thoughts and knowledge graph management. Each tool serves a distinct subdomain, though some could be consolidated (e.g., individual write tools vs. record).
Completeness3/5
The knowledge graph supports creation, reading, and deletion for entities and relations, but lacks explicit update operations for entity metadata or relation modifications. The vault side has no update or delete for thoughts, and there is no listing mechanism for sessions, leaving notable gaps in the intended lifecycle coverage.
Average 4/5 across 17 of 17 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds no extra behavioral context, such as permanence, error handling, or effects on related data. It merely restates 'delete' which is consistent with the annotations but adds no new information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence that directly states the action and scope. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple input schema and annotations covering destructive and idempotent behavior. The description states the core function, but lacks any usage context or clarification on when to choose this over similar siblings like invalidate_observations. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already provides a detailed description of the 'deletions' parameter. The tool description adds no parameter-specific meaning, so it relies on the schema. Baseline 3 is appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'specific observations from entities in the knowledge graph'. It distinguishes from sibling tools like delete_entities and delete_relations by specifying the granularity (observations within entities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or when another sibling like invalidate_observations or delete_entities would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the 'hybrid semantic + keyword search' behavior, which is useful, but it does not disclose other behavioral aspects like result ordering, pagination, or error handling. With annotations present, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the verb 'Search' and includes the key differentiator 'hybrid semantic + keyword search'. This is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema (100% coverage), annotations, and presence of an output schema, the description's brevity is acceptable. It provides a sufficient high-level summary, though it could have added more context about use cases or how this relates to sibling search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all five parameters are fully described in the schema. The tool description itself adds no extra parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'vault content' using 'hybrid semantic + keyword search', which specifies both the resource and method. However, it does not explicitly distinguish itself from sibling tools like 'search_nodes', so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context for choosing between search_thoughts and search_nodes or other siblings. It merely states what the tool does without situating it in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint true, idempotentHint true, and readOnlyHint false. The description adds no additional behavioral context beyond what annotations provide, such as permanence or effects on connected entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. Every word contributes to the meaning and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter structure, existing output schema, and annotations covering safety, the one-sentence description is sufficient for an agent to understand the tool's core action. No additional return value or parameter explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'relations' parameter with keys from, to, relationType. The description repeats 'multiple' but adds no syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete', the resource 'relations', and the scope 'knowledge graph', making it specific and distinguishable from sibling tools that delete entities or observations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like delete_entities or create_relations. It does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only (false), idempotent (true), and non-destructive (false) hints. The description adds that it targets the search database, but doesn't disclose any side effects like whether it clears the existing index or is expensive. It provides minimal extra context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 8 words, perfectly concise and front-loaded. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 optional parameters and an output schema, the description is adequate but minimal. It doesn't discuss use cases, nor does it mention that it can be scoped. Given the annotations and schema, the description is complete enough for basic invocation, but lacks deeper context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter information, leaving the schema to explain the full and session_id parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (re-index) and the object (vault content) into a specific target (search database). This is specific and distinct from sibling tools like search_thoughts, which query rather than rebuild the index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to update the search index after vault changes, but it doesn't explicitly state when to use it or mention alternatives. There is no guidance on when a full reindex vs session-specific reindex is appropriate, though that is covered by the parameter descriptions. With no exclusions mentioned, it gets a 3 for implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable context that the tool returns not just the requested entities but also all relations connected to them, which is a behavioral trait not evident from the schema alone. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with zero wasted words. It states the action, the resource, and the return value efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set (one array), strong annotations, and an existing output schema, the description is nearly complete. It does not explicitly clarify when to use this over search_nodes or read_graph, which is a minor gap given the sibling context, but overall it provides sufficient context for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'names' parameter is described as 'List of entity names to retrieve'). The description reinforces that 'names' refers to entity names, but it adds no additional syntactic or format details beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('open') and resource ('specific nodes in the knowledge graph'), and further clarifies the return value ('entities and all relations connected to them'). It is clear and distinct from siblings, but it doesn't explicitly differentiate itself from search_nodes or read_graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you know the exact names of nodes to retrieve. However, there is no explicit when-to-use vs alternatives, no exclusions, and no mention of cases where search_nodes or read_graph would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds that the thought is embedded and saved as a qnote, but it does not disclose potential side effects like vector index updates or failure modes. This adds some context beyond annotations but not deeply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It immediately states the action and mechanism, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with complete schema descriptions and an output schema, the description is sufficient. It could benefit from explicit usage guidance relative to sibling tools, but the combination of schema, annotations, and output schema fills most gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented (text, tags, session_id). The tool description offers no additional parameter-specific semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Store'), the resource ('a new thought'), and the mechanism ('embed and save to vault as a qnote'). This distinguishes it from sibling tools like search_thoughts (search) and record_decision (decisions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for capturing thoughts but does not explicitly say when to use it over alternatives like 'record' or 'create_entities'. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read/write and idempotency characteristics, and the description adds the constraint that entities must exist. However, it does not describe edge-case behavior (e.g., duplicate observations, missing entities) or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 11-word sentence that is direct and free of extraneous detail. It gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and available annotations, the description covers the core functionality. It could benefit from a note about error handling or idempotency behavior, but the output schema likely fills in return-value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameter shape (list of dicts with entityName and contents). The description adds the semantic requirement that entities must already exist, which is not stated in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('new observations to existing entities in the knowledge graph'), using a specific verb and object. It distinguishes from sibling tools like 'create_entities' (which creates entities) and 'delete_observations' (which removes observations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. However, the action is clear and the sibling context implies its use for enriching existing entities. It lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover destructive and idempotent hints. The description adds valuable behavioral context: it cascades to associated relations and handles multiple entities batch-wise. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and scope. No filler words; every element is meaningful and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter deletion tool with output schema and annotations, the description sufficiently covers purpose, scope, and cascade behavior. Could be slightly more explicit about irreversibility or partial failure, but generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (single entityNames parameter described as 'List of entity names to delete'). Description adds no further parameter detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('delete') and resource ('entities and their associated relations'), clearly distinguishing from sibling tools like delete_relations. It also specifies batch handling ('multiple'), making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you want to delete entities and their relations) but does not explicitly state when to use this tool vs alternatives like delete_relations or create_entities. No exclusions or preconditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring idempotentHint=true and destructiveHint=false, the description adds concrete mechanics: it sets a status field and a timestamp, and optionally records a superseding belief. This gives context beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a header line, front-loading the purpose. No filler or redundant repetition of schema/annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage, an output schema, and annotations, the description covers the essential behavioral contract: it states the action, the exact state change, and the optional input semantics. It doesn't address edge cases like non-existent observations, but that level of detail is typically not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no additional parameter-level detail beyond what the schema already specifies (e.g., superseded_by matches 'Optional description of what replaced these beliefs'). It does mention the automatic invalidated_at date, but that's not a parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Mark observations as invalidated' with a specific state change ('Sets status='invalidated' and records invalidated_at date'). This distinguishes it from deletion siblings by framing it as a soft invalidation with belief revision tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'belief revision tracking' and the optional 'superseded_by' parameter, but it never explicitly says when to choose this over delete_observations or revise. No when-not guidance or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable context by revealing that the tool reads the markdown file directly, implying it may bypass indexes or caches, and that the content is full (not truncated). This goes beyond what annotations provide, earning a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and purpose. There is no redundant information or filler, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, clear annotations, and an output schema present, the description is complete enough. It conveys the key behavioral detail (direct file read) and the output schema covers return values. No further elaboration is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the only parameter, session_id, has a clear description with an example. The tool description does not add further parameter-level meaning, but the schema already carries the semantic load, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get full content of a session by reading the markdown file directly.' It specifies a concrete action (get), a resource (session content), and the method (direct markdown file read), which distinguishes it from sibling tools like search_thoughts or open_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by clearly defining what the tool does, but it does not explicitly state when to use it versus alternatives or provide exclusions. It lacks guidance such as 'Use this when you need the raw session content rather than search results.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the description needs only to add non-obvious behavioral context. It discloses a crucial behavior: results are capped, and total_matched is returned to signal truncation. This goes beyond annotations and helps the agent understand that search results may be incomplete yet explicitly indicated. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences totaling 21 words. It front-loads the primary purpose and then adds a single valuable behavioral nuance. No redundancy or wasted words; every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and full parameter coverage in the schema, the description doesn't need to explain return values or parameters. It adds the essential nuance about result capping and total_matched, which is critical for the agent to interpret search results correctly. The description is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are fully documented in the schema. The description adds no parameter-specific meaning (e.g., what query matches against, what domain/entity_type filter, or how limit/max_relations work), which is already covered. Given high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search the knowledge graph'—a specific verb with a clear resource. It differentiates from siblings like search_thoughts (which likely targets thoughts specifically) and read_graph (a broader read operation) by focusing on search behavior. The added boundedness detail further distinguishes it as a search with explicit result handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this to search the knowledge graph. However, it does not explicitly say when to prefer this over alternatives like search_thoughts or read_graph, nor does it mention exclusions or prerequisites. The context is clear but lacks explicit guidance on alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it requires active voice, lists canonical relation types, and warns that non-standard types are accepted but return a warning. This complements the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first states the purpose, the second lists canonical types, and the third warns about non-standard types. It is concise, front-loaded, and every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the annotations, and the presence of an output schema, the description covers the essential aspects: purpose, valid relation types, and warning behavior. It could be more explicit about when to use the tool versus alternatives, but it is reasonably complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'relations' parameter as 'List of dicts with keys: from, to, relationType,' so coverage is 100%. The description adds value by specifying the active voice requirement, enumerating canonical types, and noting the warning for non-standard types, which enriches parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create multiple new relations between entities.' This is a specific verb+resource combination that distinguishes it from sibling tools like create_entities (which creates entities) and delete_relations (which removes relations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating relations and provides canonical relation types, but it does not explicitly state when to use this tool versus alternatives or when not to use it. It lacks explicit exclusions or references to other tools, so guidance is present but not fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false), idempotent (idempotentHint=true), and non-destructive (destructiveHint=false). The description adds context about the rationale for the rejected field, but does not directly disclose important side effects such as whether this creates a new record or updates an existing one (the 'supersedes' parameter hints at replacement but is not explained). This is acceptable given the annotations, but the description could add more operational clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence immediately states the purpose and fields. The subsequent sentences justify the 'rejected' field without redundancy. Every sentence contributes to understanding, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema (100% coverage) and presence of an output schema, the description provides enough context for selecting and invoking the tool. It clarifies the main purpose and the distinguishing rejected field. It does not explicitly compare with sibling tools like 'record' or 'store_thought', but the focus on decisions is strong enough. A brief note on when to use this versus those siblings would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantic value by highlighting the importance of the 'rejected' parameter, explaining why it is the core of a decision record. This goes beyond the schema and helps the agent understand how to populate that field correctly. However, it does not elaborate on other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Record') with a clear resource ('a decision') and enumerates the core fields ('what was chosen, what was rejected, and why'). It distinguishes itself from siblings like store_thought or record by focusing on decisions and emphasizing the rejected alternatives, making the tool's intent unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for recording decisions, and it provides context on why this is valuable (preserving rejected alternatives). However, it does not explicitly mention when to use this over siblings like store_thought or record, nor does it state any exclusions or alternatives. This is clear context without explicit comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only safety is covered. The description adds useful behavioral details beyond annotations: pagination with offset/limit, the summary mode, and what the summary contains (names + types + observation counts). It doesn't mention all nuances like relation handling in default mode, but the added context is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose. Every sentence adds value: the core action, default pagination, and summary option. No fluff or repetition. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and full schema coverage for parameters, the description adequately covers the main use case (read whole graph) and the two modes. It could mention performance implications of reading the entire graph or explicitly clarify that relations are also returned in the default paginated result, but it is mostly complete for a read tool with pagination and summary options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema by specifying what summary=True provides ('names + types + observation counts') and clarifying default pagination behavior. This supplements the schema, justifying a 4 rather than a 3, though it doesn't heavily elaborate on other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read the entire knowledge graph — all entities and relations.' It uses a specific verb (read) and resource (knowledge graph), and distinguishes itself from siblings like search_nodes and search_thoughts by emphasizing the whole graph rather than focused search. The mention of summary mode adds further clarity about the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to read the entire knowledge graph, as opposed to searching. It provides clear context about default behavior (full entities with pagination) and the alternative summary mode. However, it does not explicitly name sibling tools as alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavioral traits beyond annotations: atomicity ('a batch that is half-valid writes nothing'), validation before writing, entity field constraints, and relation vocabulary handling (synonyms folded, unknown rejected). Annotations already indicate idempotent and non-destructive behavior, but the description adds meaningful context. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then systematically details atomicity, entity fields, observations, and relations. Every sentence earns its place, though the length is justified by the tool's complexity. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's complex behavior comprehensively: atomic writes, field specifications, observation structure, and relation rules. With an output schema present, return values are handled elsewhere. Minor gaps include not explicitly stating failure handling beyond 'writes nothing' or listing the canonical relation vocabulary, but overall it is highly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the schema descriptions are terse ('Entities to create or merge into'). The description compensates by elaborating entity fields (name, entityType, domain, epistemic, visibility), observation formats (string or object with kind), and relation constraints. This adds significant semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Write entities, relations and observations in one validated, atomic call', using a specific verb and naming the exact resources. It further distinguishes the tool as 'the single write path', separating it from sibling write tools like create_entities or add_observations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'This is the single write path' gives strong usage guidance, implying it is the preferred route for any write operation. The atomicity and validation details also clarify when this tool should be chosen over non-atomic alternatives, though it stops short of explicitly naming alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (write, idempotent, non-destructive), the description reveals that the tool preserves superseded observations for later audit ('dated and linked') and imposes an ordering constraint for relations. This adds significant behavioral context not present in the annotations. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary action, followed by a rationale and a conditional guideline. Every sentence carries useful information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, full schema coverage, and an output schema, the description sufficiently covers the tool's purpose, behavior, and parameter prerequisites. It explains the non-destructive nature, the archival intent, and the ordering constraint, making it complete enough for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 4 parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by explaining the role of superseding_entity and the need to record that entity first, enhancing the schema's plain description. However, it doesn't enrich superseded_by or the other parameters beyond their schema text, hence a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: marking observations as no longer held and linking what replaced them. It explicitly distinguishes itself from deletion ('Deliberately not a delete') and explains the archival rationale, making it distinct from sibling tools like invalidate_observations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use it by contrasting with deletion ('Deliberately not a delete') and explains why preserving is important. It also gives a conditional prerequisite for superseding_entity, telling the agent to record that entity first. However, it doesn't explicitly name alternative tools for simpler invalidation, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing merge behavior, default entityType, temporal metadata, and activation tracking. These details explain the tool's non-destructive, idempotent nature and side effects on existing entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main action, and uses bullet points for clarity. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description fully covers purpose, parameters, and behavioral effects. It explains merge semantics, defaults, and metadata, providing an agent with sufficient information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema simply lists keys, the description enriches them with essential semantics: required name, default 'concept' for entityType, observations as list of strings, and the epistemic enum. This fills in type/default/enum details missing from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create multiple new entities in the knowledge graph', specifying a distinct verb and resource. It also notes merging behavior for existing names, which distinguishes it from sibling tools like create_relations or delete_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool can also merge observations into existing entities, implying an upsert use case. However, it does not explicitly mention when to prefer alternatives like add_observations, so there are no formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ygtalp/rawthink-mcp'

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