hippocampus

by kaidewu01

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: v0.1.0
Disambiguation4/5
The three prefixed domains (personal/tech/conversation) are clearly separated, and most tools target a distinct resource or action. Within personal, however, personal_provenance and personal_get_node both expose raw document text, and personal_neighbors/personal_graph both return graph-like views, requiring careful reading of descriptions.
Naming Consistency4/5
The personal_/tech_/conversation_ prefixes create clear namespaces, and most tools follow a verb_noun pattern. A few personal_ names are bare nouns (provenance, neighbors, graph) rather than action verbs, which is a minor but noticeable inconsistency.
Tool Count3/5
21 tools is on the heavy side for a single MCP server, even though the load is distributed across three distinct modules. The count feels manageable but exceeds the typical well-scoped range.
Completeness4/5
Core workflows are well covered: creating and linking entities, adding documents/attachments, searching and retrieving content, updating tech observations, and importing/auditing conversations. The main gaps are the lack of a general delete/detach operation and limited batch listing, but these can usually be worked around.
Average 3.3/5 across 21 of 21 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that the output is a graph structure containing nodes and edges with styling, but it does not disclose side effects (if any), whether data is read-only, how depth/focus filtering affects the subgraph, or what 'only_len' means. This is too sparse for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and wastes no words, which is structurally good. However, it is under-specified to the point of being cryptic, and the internal reference '§3.10, D17' adds no value to an AI evaluator. It is concise but not appropriately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three undocumented parameters, no annotations, and only a minimal description of the return shape. Although an output schema exists, the description does little to clarify how parameters influence the result or when this tool should be preferred. The information density is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of depth, focus_id, or only_len. The agent is left with bare parameter names and defaults, with no help on how they shape the returned subgraph. The description does not compensate at all for the missing schema documentation.
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 identifies a specific resource and outcome: a subgraph of nodes and edges with color/icon, ready for visualization. This is clear enough to distinguish it from sibling tools like personal_neighbors or personal_get_node, which imply narrower or single-node operations, though it lacks an explicit verb like 'retrieve' or 'build'.
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?
There is no guidance on when to use this tool versus alternatives such as personal_neighbors or personal_search. The internal reference '§3.10, D17' provides no actionable information to an AI agent, and no when-to-use or when-not-to-use conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the operation creates a directed, typed edge (implying a write), but says nothing about idempotency, duplicate-edge handling, whether referenced entities must exist, side effects, or authorization requirements. The behavioral disclosure is the minimum possible for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words, which is structurally efficient. However, it is under-specified for a 7-parameter tool, and the '(R4)' reference reads as internal jargon that an external agent cannot resolve. Conciseness is achieved at the expense of necessary meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with 7 parameters, no annotations, and 0% schema coverage, a one-sentence description is inadequate. The agent cannot determine edge-type semantics, required entity relationships, confidence/date field purposes, or expected behavior on conflicts. The presence of an output schema partially helps, but not enough to offset the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the seven undocumented parameters. It provides no meaning for src/dst (which entity IDs are involved), what 'type' values are legal, what confidence or occurred_at represent, or how note and source_doc_id relate to the edge. The description adds zero parameter-level value.
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 ('Crea') and resource ('una arista dirigida y tipada entre dos entidades'), making the core function clear: creating a typed, directed edge between entities. It does not name or differentiate from siblings like personal_attach or personal_upsert_entity, but the edge-versus-entity distinction is implicitly visible. The cryptic '(R4)' suffix adds minor noise but does not obscure the purpose.
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?
There is no guidance on when to use this tool versus alternatives such as personal_attach or personal_upsert_entity. No prerequisites (e.g., whether src/dst entities must already exist), no context, and no exclusions are provided. An agent must infer the use case entirely from the tool name and bare description.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose one important behavioral trait: the transcript is complete and not truncated. However, it omits other behavioral context such as the effect of only_len, pagination, or error/permission behavior.
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 a single, short, front-loaded sentence with no filler. The '§3.15' reference is cryptic and adds little for an AI agent, but the overall structure is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and covers return values, the description does not compensate for the 0% parameter schema coverage and does not position the tool among its siblings. An agent would struggle to know when to call this versus conversation_search or conversation_import, and it cannot infer the semantics of only_len.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters id and only_len are completely undocumented in the schema. The description does not explain either parameter or how only_len interacts with the 'sin truncar' guarantee, leaving the agent unable to understand the meaning of only_len=true.
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 conveys that the tool returns a complete conversation transcript and explicitly adds the 'sin truncar' qualifier, which helps distinguish it from truncated or summary-style retrieval. However, it is phrased as a noun phrase rather than using an explicit verb like 'returns' or 'gets.'
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 gives no when-to-use guidance, prerequisites, or alternatives. It does not mention conversation_search, conversation_import, or any condition for choosing this tool over them; 'sin truncar' only weakly implies the use case of needing a full transcript.
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?
The description discloses an important behavioral trait: it reuses the existing id if the entity already exists, rather than creating a duplicate. However, with no annotations, it does not explain update behavior for optional fields like aliases or summary, side effects, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, which is good, but the parenthetical '(R3)' is an internal reference that adds no meaning for an AI agent. It is concise but includes an unexplained artifact that slightly reduces usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no parameter descriptions, the description leaves important gaps: field semantics, partial-update behavior, required type existence, and differentiation from merge/create tools. The output schema covers return values, but not these operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or usage of any parameter: name, type, aliases, or summary. The mention of 'id' refers to an entity property, not an input parameter, so the agent gains almost no parameter-level insight.
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 uses a specific verb, 'Crea/actualiza', and names the resource, 'entidad', making the upsert purpose clear. It is distinguishable from read-oriented siblings like personal_find_entity, though it does not explicitly contrast with personal_merge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to prefer this tool over alternatives such as personal_merge or personal_create_type. The upsert semantics are implied by the description, but no exclusions or decision criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action 'Guarda' (saves) and clarifies the project parameter, without mentioning whether it overwrites existing entries, requires prior initialization, has side effects, or how it interacts with other tech_* tools. Behavior beyond the basic save action is opaque.
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 two sentences with the core action front-loaded and the project parameter rule second. Each sentence earns its place and there is no filler, though the brevity leaves substantial semantic gaps for a 10-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no annotations, and 0% schema description coverage, the two-sentence description is under-specified. It explains only one parameter and omits usage context, return behavior, and relationships to sibling tools, leaving an agent to guess most of the input contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so every parameter required explanation. The description only clarifies 'project' as basename del repo (D13, R8) and generically calls the content an observation/message. The remaining eight parameters (type, files, status, summary, repo_path, next_steps, session_id) are entirely unexplained, leaving the agent to infer their meaning from names alone.
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 uses the specific verb 'Guarda' (saves) and identifies the resource as 'una observación/mensaje' (an observation/message), making the core action clear. The reference to 'mem_save' provides a familiar analog, but it doesn't explicitly distinguish tech_save from siblings like tech_update or the personal_* tools.
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?
There is no explicit guidance on when to use tech_save versus alternatives such as tech_update, tech_get, or personal_add_reflection. The reference to mem_save implies an analogous use case but does not state conditions, exclusions, or when a sibling tool 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It clarifies that the result is raw source text rather than the node, but it does not state read-only behavior, side effects, permissions, or pagination/limits. The disclosure is minimal.
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 a single compact sentence and front-loads the core resource. However, conciseness is achieved at the expense of essential parameter context, and the unexplained 'F1' reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be detailed, but the description fails to define the required parameter or the optional flag, and the cryptic 'F1' leaves a gap. For a simple provenance lookup this is incomplete but not entirely unusable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain 'id' or 'only_len'. An agent cannot determine what 'id' refers to or what 'only_len' controls without external context, and the cryptic '(F1)' adds no parameter meaning.
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 names the resource ('documentos de los que salió un nodo') and the output ('el texto crudo asociado'), and explicitly contrasts with the bare node, helping distinguish it from personal_get_node. However, it lacks an explicit verb and the 'F1' qualifier is unexplained.
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 phrase 'no el nodo pelado' implies this tool should be used when source/provenance documents are needed rather than node retrieval, but it does not name sibling tools or provide explicit when-to-use/when-not-to-use guidance. Usage is implied rather than stated.
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?
Since no annotations are provided, the description carries the behavioral disclosure burden. It does add useful information: this is a retrieval operation and matches via full-text search over title and content. However, it doesn't disclose filter behavior, result limits, or the semantics of the 'only_len' flag, so transparency is only partial.
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 a single, compact, front-loaded sentence with no redundant wording. The internal reference '§3.15' is likely not actionable for an AI agent, and the brevity comes at the cost of missing parameter detail, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description leaves three parameters unexplained and gives no guidance on selecting this tool among the many sibling search/get tools. The output schema may cover return shape, but invocation semantics and filter behavior are under-specified for a tool with four parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate for the four undocumented parameters. It indirectly implies that the 'query' parameter is matched against title and content, but 'source', 'project', and 'only_len' remain unexplained.
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 action ('Recupera'), a clear resource ('conversaciones de auditoría'), and a specific method ('FTS, título + contenido'), so the core purpose is unmistakable. It doesn't explicitly distinguish this tool from siblings like conversation_get or personal_search, so it stops 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?
No guidance is provided about when to use this tool versus conversation_get, personal_search, or tech_search. There are no when-not-to-use conditions, alternative tool mentions, or usage context beyond a reference to section §3.15.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavior disclosure. It only says 'updates' and gives a status example; it does not state whether omitted fields are preserved, whether nulls clear values, or what side effects the update has.
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?
A single sentence with a concrete usage example. The core action is front-loaded, and there is no filler; '(R8)' is minor and does not hurt clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter mutation tool with zero schema descriptions and no annotations, this is too thin. It lacks partial-update semantics, nullable-field meaning, and any guidance about which combinations of fields are valid. The output schema may cover return values, but input behavior is underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only clarifies status='done' (via example) and implies id targets the observation; files, content, summary, and next_steps remain semantically unexplained.
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?
States the action clearly ('Actualiza una observación') and gives a concrete example (closing a task with status='done'). It doesn't explicitly contrast with siblings, but the update verb plus the observation resource are enough to distinguish it from tech_save, tech_get, and tech_search.
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 by the verb: use this when updating an existing observation. However, there is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternative tools such as tech_save, so an agent must infer tool selection from names and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It does disclose a meaningful behavior: deduplication by SHA. It does not mention side effects, permissions, or whether existing data is modified, but the core save-and-dedupe behavior is present.
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 very short and front-loaded with the main purpose. Both sentences earn their place, though 'R12' is cryptic and the terse style sacrifices some useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, one required, and no parameter documentation in the schema, the description is too sparse to fully guide invocation. It doesn't explain how `node_id` or `document_id` relate to the attachment, or what `mime` should contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies `data_base64` and `source_path` as alternative input methods. It leaves the required `mime` parameter and the `source`, `node_id`, and `document_id` parameters unexplained, so an agent may not know how to populate them correctly.
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 a specific action ('Guarda un adjunto') and resource ('imagen'), which aligns with the tool name. It doesn't explicitly distinguish from siblings, but the resource and action are specific enough that an agent can infer its purpose.
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 provides usage guidance by telling the agent to pass either `data_base64` or `source_path`. However, it doesn't mention when to prefer this tool over siblings like `tech_save` or other personal_* tools, nor does it state exclusions or contextual conditions.
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?
There are no annotations, so the description carries the burden of behavioral disclosure. It does convey that this is a retrieval operation using full-text search, which strongly implies read-only behavior. However, it does not explain how the project or only_len parameters affect results, nor does it describe any other behavioral nuances.
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 a single, front-loaded sentence that wastes little space. The '(R8)' tag is cryptic and adds little value for an agent, but it is small noise rather than a structural problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details are less critical, but the description still omits important operational context: what scope 'observaciones' refers to, how project filtering behaves, what only_len returns, and when this differs from sibling search tools. For a tool with no annotations and three parameters, this is not complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the parameters. It implies that 'query' is the full-text search string, but says nothing about 'project' or 'only_len'. This is only partial compensation for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Recupera') and resource ('observaciones') and the method (FTS), so an agent knows this is a full-text search tool. It does not explicitly differentiate from sibling search tools like personal_search or conversation_search, beyond the 'observaciones' focus and the reference to mem_search.
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 phrase 'como mem_search' implies the intended use case: perform a full-text search similar to the existing mem_search tool. However, it does not explicitly say when to prefer tech_search over alternatives, nor does it describe exclusions or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does disclose a meaningful behavioral trait: the result is complete and not truncated. It does not address not-found behavior, permissions, errors, or how `only_len` interacts with the 'no truncation' promise, but for a simple getter this is partial rather than absent disclosure.
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 a single front-loaded sentence that states the core behavior and adds a useful analogy via `mem_get_observation`. The trailing '(R8)' is process metadata that adds no value for an agent, which prevents a perfect score.
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 is relatively simple and has an output schema, so return-value details are covered elsewhere. However, the optional `only_len` parameter is not explained, and there is no explicit guidance on choosing this over sibling tools. The description is adequate for basic use but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate for missing parameter meaning. It does not mention `id` or `only_len`; `id` is inferable as the observation identifier from 'observación,' but `only_len` remains unexplained. This is a clear gap because the optional boolean could change the output shape.
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 that the tool returns the complete content of an observation without truncation, establishing the verb/resource relationship. It helps differentiate from list/search siblings by emphasizing full, untruncated content. However, it does not explicitly name or contrast a sibling tool, so it stops short of maximum clarity.
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 when to use the tool: when full observation content is needed rather than a truncated view. The reference to `mem_get_observation` provides an analog, but there is no explicit when-not-to-use guidance or comparison to siblings like `tech_search` or `tech_list_open`. The usage context is present but only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It does add a valuable behavioral trait by specifying idempotency keyed on (source, external_id), but it does not disclose what happens on conflict, whether this creates/updates records, or any side effects beyond the import.
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 very short, front-loaded with the core purpose, and then adds the key behavioral detail of idempotency. There is no unnecessary padding, though the opaque '(§3.15, D25)' reference is mildly cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nine parameters, no annotations, and no in-schema parameter descriptions, the description is too thin to be fully actionable. It omits important context such as expected content format, source value domain, how optional fields are used, and the effect of duplicate external_id imports.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies source and external_id as the idempotency tuple. The required title and content parameters, plus all optional parameters, receive no semantic explanation beyond their names.
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 states a specific action and resource: importing a raw transcript from an AI console. This clearly distinguishes the tool from sibling read/search tools like conversation_search and conversation_get.
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?
There is no explicit guidance on when to use this tool versus alternatives, and no exclusions or prerequisites. The import action is implied, but the description does not help an agent decide between this and other write/import tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects, and it does state that a new document is created and entity links are added. It does not mention whether links are appended or replaced, whether permissions are needed, or whether the operation is idempotent.
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 short sentence with no filler. The core action and linking behavior are front-loaded, and every phrase earns its place.
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 two-parameter tool with an output schema, the description covers the essential create-and-link behavior. However, the unclear 'provenance, R5' qualifier and the lack of detail about optional related_ids leave some ambiguity for an agent selecting or invoking the 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 0%, so the description must compensate. It maps 'texto crudo' to the text parameter and 'entidades' to related_ids, but it does not explicitly say that related_ids are integer entity IDs, that they are optional, or how the linking is performed.
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 concrete action: 'Guarda el texto crudo como documento' and the linking behavior 'lo enlaza a las entidades'. This makes the tool's purpose reasonably clear and distinguishes it from save-only or link-only siblings, though the meaning of 'provenance, R5' is not explained.
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 use case: persist raw text as a document and link it to related entities. However, it does not explicitly contrast with sibling tools like tech_save, personal_link, or personal_upsert_entity, so an agent has to infer when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the core filtering behavior (only type='task' and status='open' items are returned), which is genuinely behavioral. However, it is silent on other behaviors such as pagination, ordering, result limits, or what the only_len flag changes about the response.
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?
A single, front-loaded sentence in Spanish states the action first and the filters immediately after. The only waste is the '(R8)' traceability tag, which adds no value for an agent deciding whether to invoke the tool.
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 is simple and has an output schema, so return values need not be described. But the two optional parameters are entirely undocumented, and with no annotations the description is the sole source of guidance — thin for anything beyond a default invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate: neither 'project' (presumably a project filter) nor 'only_len' (presumably a count-only mode) is explained anywhere. An agent cannot know how to filter by project or request a length-only result.
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 states a specific verb ('Lista' — lists), a precise resource (open tasks), and embeds the exact filter predicates (type='task', status='open'). This clearly distinguishes it from sibling tools like tech_get and tech_search, which are single-node retrieval and search operations respectively.
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 usage context is implied by the name and purpose — you call it when you need the list of open tasks — but the description gives no explicit when-to-use guidance, exclusions, or references to alternatives like tech_search or tech_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It says the tool adds a type, but it does not mention side effects, idempotency, whether existing types are overwritten, permissions, or scope of the catalog change. For a mutating tool, this is a significant transparency gap.
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, dense sentence that front-loads the core action and includes the most critical constraint. There is no filler or repetition of schema information.
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 five parameters, no annotations, and no schema-level descriptions, so the context is only partially covered. The essential invoking condition (`target` ∈ node|edge) is present, and an output schema exists, but behavioral context such as idempotency, error conditions, and whether the catalog addition is persistent is missing. It is adequate for a simple call but not fully 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 0%, so the description must compensate for the missing parameter documentation. It does add crucial meaning for `target` by restricting it to node|edge, but it does not explain the semantics of `name`, `icon`, `color`, or `description` beyond their obvious names. The compensation is partial, not complete.
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 states a specific action (Añade), a specific resource (tipo de nodo/arista), and a specific location (catálogo en runtime). It also disambiguates the meaning of `target` as node|edge, which is essential and not present in the schema. This clearly separates it from sibling tools that manage entities or links.
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 use case: creating a node/edge type in the runtime catalog. The 'runtime' qualifier and the explicit `target` domain give useful context. However, it does not explicitly contrast with alternatives or state when not to use the 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?
Anotaciones ausentes, así que la descripción carga con la transparencia. Comunica sin ambigüedad que la operación es de búsqueda/no mutación y que su retorno son candidatos, no una entidad creada ni un resultado exacto. No declara efectos secundarios porque no parece tenerlos; aun así, no detalla forma de los candidatos ni límites.
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?
Dos frases concisas con la información clave al frente: acción, momento de uso y tipo de retorno. No hay relleno ni repetición del nombre.
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?
Para una herramienta simple de búsqueda con output schema, la descripción es mínimamente viable y fija el contexto de uso, pero deja lagunas claras en el significado de parámetros como 'only_len' y en cómo se interpreta la búsqueda (exacta, difusa, filtrable).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
La cobertura del schema es 0% y la descripción no compensa. Solo aporta contexto general sobre 'query' (buscar entidad); 'type' y especialmente 'only_len' quedan sin explicar. No añade semántica más allá de lo que ya se infiere del esquema.
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?
La descripción usa un verbo específico ('busca'), define el recurso ('entidad') y declara el resultado ('Devuelve candidatos'). La frase 'ANTES de crearla' y '(buscar-y-enlazar, R3)' la sitúan en un flujo concreto y la diferencian implícitamente de herramientas de creación como personal_upsert_entity o personal_merge.
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?
Indica claramente cuándo usarla: antes de crear una entidad para enlazarla. No menciona alternativas ni exclusiones explícitas, pero el contexto temporal es suficiente para que un agente distinga este paso de creación/actualización.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses useful behavioral traits: the response includes complete summary and raw docs without truncation, and `not_found` is returned if the node does not exist. It does not mention auth or side effects, but this is a read-oriented tool and the key error condition is covered.
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 compact and well-structured: main capability first, then usage context, then error behavior. Every sentence adds value and there is no repetitive filler.
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 get-by-id tool, the description covers the main purpose, the expected output style, and the not-found case. However, the `only_len` parameter is left unexplained, which is a meaningful gap since it may alter the returned content. The presence of an output schema helps, but parameter semantics remain incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies `id` identifies the node, but it never explicitly explains the parameters. More importantly, `only_len` is completely undocumented despite being a boolean that likely changes the response shape; an agent cannot confidently decide whether to set it.
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 states a specific verb and resource: it retrieves the complete content of a node, including full summary and raw untruncated docs. It also distinguishes itself from siblings by positioning itself as the targeted shortcut after viewing a node on the map via `personal_neighbors`.
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?
It gives clear context for use: after seeing a node in the map with `personal_neighbors`, use this tool to read everything hanging from that node. It does not explicitly list exclusions or alternative tools, but the intended workflow is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses truncation behavior, exposes truncated/full character hints, reports doc_count/doc_char_count, and explains that max_chars=0 disables truncation. It does not mention read-only guarantees, result limits, or sorting, but these are less critical for a search tool with an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with only three sentences covering purpose, behavior, and the alternative tool. The cryptic 'R7, DL4' reference adds some noise and prevents a perfect score.
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 moderate-complexity tool with an output schema, the description covers the main invocation behavior, truncation semantics, and the related retrieval tool. The main omission is only_len, and there is no explicit statement about side effects or limitations, but the overall picture is sufficient for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains query semantics, text_max_chars, and summary_max_chars including the sentinel value 0. However, the only_len parameter is never explained, leaving a meaningful gap despite the boolean default.
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 states a specific action ('Búsqueda keyword FTS5') and the exact resources/fields searched: name/alias/summary and document text. It also distinguishes its role as the cheap first step of a flow, clearly separating it from the retrieval tool personal_get_node.
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?
It explicitly positions the tool as 'Primer paso del flujo: barato' and tells the agent to expand full results with personal_get_node. This gives clear usage context and a named alternative, though it does not explicitly rule out use cases handled by tech_search or conversation_search.
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?
No hay anotaciones, así que la descripción asume la responsabilidad. Declara efectos importantes: crea o abre la BD, siembra tipos y Self, cachea el engine y es idempotente. No detalla posibles efectos sobre una BD ya existente, pero 'crea/abre' e 'idempotente' mitigan esa ambigüedad.
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?
Es concisa y va al grano, con la acción principal al inicio y detalles de implementación después. La referencia a 'D18' añade contexto interno pero no es esencial; en general cada frase aporta información útil.
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?
Para un solo parámetro y con esquema de salida presente, la descripción cubre el propósito, la idempotencia, el cacheo y la relación con el CLI. Podría precisar qué ocurre si la BD ya existe o si el sembrado de tipos es condicional, pero en conjunto es suficiente para invocarla correctamente.
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?
Aunque la cobertura del esquema es 0%, la descripción sí aclara el significado del único parámetro: path es la ubicación de la BD. Es suficiente para un parámetro string obligatorio, aunque no da más detalles sobre formato o restricciones.
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?
La descripción usa un verbo específico y un recurso concreto: 'crea/abre la BD en path, siembra tipos y el Self'. Deja claro que es la inicialización del almacén personal y no se confunde con las operaciones de consulta o escritura de entidades que aparecen en los hermanos.
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?
Explica que comparte orquestación con el CLI 'hippocampus init', lo que ayuda a decidir cuándo usar esta herramienta en lugar de la CLI. También indica que añade comportamiento específico del servidor, aunque no menciona explícitamente cuándo no usarla frente a las demás herramientas personales.
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?
With no annotations, the description carries the full burden and does so well: it discloses the default empty documents payload, the doc_count/doc_char_count signal, the summary_max_chars=0 opt-out, and the reversible but dangerous include_documents=True mode. It even warns about payload explosion from previous behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence in the description adds a distinct fact: purpose, phase, default payload, expansion guidance, trim control, and the hard include_documents rule. It is dense but not padded, and the most important purpose line is front-loaded.
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 tool with no annotations and no schema param descriptions, the description covers the main call pattern, safety limits, and expansion workflow; the output schema can carry return structure. It is still not fully complete because only_len and id semantics are left to inference, but an agent has enough to call it safely in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so parameter explanation must come from the description. It explains include_documents, summary_max_chars, and depth constraints, but leaves only_len and the required id parameter implicit, which is a clear gap.
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 opening line defines a cheap neighborhood map with nodes, edges, trimmed summary, and budget, and later positions it as Phase A of a two-phase read. This is specific, but the description never states a verb and does not explicitly differentiate it from sibling personal_graph, so it stays below the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames the tool as Phase A of a two-phase read and points to personal_get_node as Phase B for expansion. It also gives a hard exclusion rule: never use include_documents=True with depth>=2 because it saturates the graph. This meets the explicit when/when-not/alternative bar.
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?
With no annotations present, the description carries the full burden and does so well. It discloses that src is deleted, edges/provenance/attachments are repointed to dst, aliases are merged, UNIQUE constraints are respected, and the operation is atomic. These are important behavioral traits beyond what the schema shows.
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 compact and front-loaded, with the core action in the first sentence and important constraints in the second. The only drawback is the cryptic internal reference 'F1, §5 riesgo #3,' which provides little operational value to an agent and adds noise.
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 destructive merge tool with no annotations, the description covers the key invocation contract: what is deleted, what is redirected/merged, atomicity, and the Self restriction. It does not discuss error cases or permissions, but an output schema exists and the core behavior is sufficiently described.
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 only lists two integers with no descriptions, so the description adds essential role semantics: `src` is the duplicate to be merged/deleted and `dst` is the surviving node. This resolves the main ambiguity for invoking the tool. It does not add more detail, but none is critically needed.
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 specifies the action and resource: 'Fusiona el nodo duplicado `src` en `dst` (superviviente) y borra src' — a merge operation with a defined survivor and source. It also distinguishes itself from sibling tools by stating the unique merge behavior and the Self restriction.
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 gives clear usage context: use this when a duplicate node must be merged into a surviving node. It also provides an explicit exclusion: 'No permite fusionar el Self como origen.' It does not name alternative tools, but no sibling appears to cover merge behavior, so the guidance is sufficient.
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:

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

Score Badge

Copy to your README.md:

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

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/kaidewu01/hippocampus'

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