people-memory-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct (graph_status, search_people, get_person, add_fact, record_interaction, find_intro_path, stale_contacts). There is minor overlap between read_query/write_query and the higher-level person/interaction tools, since an agent could use write_query to bypass the intended workflows, but descriptions clarify their guarded, analysis-focused roles.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout: graph_status, search_people, get_person, remember_person, add_fact, record_interaction, connect_people, find_intro_path, stale_contacts, read_query, write_query. The naming is clean and predictable.
Tool Count4/5
11 tools is reasonable for a people-memory graph server. Each tool covers a distinct purpose (querying, creating, interactions, relations, analysis). It's slightly on the higher end but not excessive, and no tool feels redundant.
Completeness4/5
The surface covers search, get, create/update (remember_person), add facts, record interactions, connect people, path finding, and staleness analysis. Minor gaps include no delete/forget person operation and no direct relationship update/removal tool, but core lifecycle and analysis workflows are well covered.
Average 3.2/5 across 11 of 11 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 52 commits in the last 12 weeks
- Last stable release on August 3, 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Attach a durable fact' implies persistence and mutation but doesn't state whether it appends, overwrites, or requires existing person records. It doesn't disclose idempotency, conflict behavior, or what 'durable' means relative to other storing tools. The ambiguity-checking instruction is a behavioral note but too shallow to constitute real transparency.
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?
One short sentence plus an instruction fragment. It is efficient and front-loaded with the core purpose. However, the 'Ask the user if the name is ambiguous' fragment is oddly placed and could be integrated more clearly as a usage guideline.
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 6 parameters, no annotations, and a low-coverage schema, so the description must compensate for that complexity, but it does not. An output schema exists, which lowers the burden for explaining return values, but the description still leaves major gaps: what 'durable fact' entails, how person_name disambiguation works, and parameter semantics are all unexplained.
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 explain the parameters. It provides essentially zero parameter information — no explanation of how key/value/number/fact_date/confidence relate, which are optional, or what fields are needed for a complete fact. With 6 parameters at 0% coverage, the description's failure to describe any of them is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it attaches a durable fact to a person, giving a specific verb and resource. However, the phrase 'Ask the user if the name is ambiguous' confuses the purpose — it reads as an instruction to the agent about conversation behavior rather than clarifying what the tool does. It lacks the behavioral specificity needed to distinguish it from siblings like remember_person or record_interaction.
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 on when to use this tool versus alternatives. There's no mention of when a fact should be stored via this tool rather than via remember_person or record_interaction. The 'ask the user if the name is ambiguous' hint gives a minor usage signal but is vague and doesn't establish exclusions or alternatives.
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. However, it doesn't clarify what 'strong relationships' means (thresholds heuristics), what 'recent' is defined as, whether the output is a count or list, or whether the query could be expensive for large graphs. The min_days parameter hints at recency definition, but the description doesn't surface key behavioral semantics beyond the parameter.
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?
One sentence, zero waste, front-loaded with the core function. Efficient and clear in its brevity. No extraneous content.
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 the tool has no annotations, no schema descriptions (0% coverage), and 10 sibling tools, the description is under-specified. It does have an output schema which explains return structure, but the key open questions — definition of 'strong', definition of 'recent', and relation to sibling tools — remain unaddressed. The min_days parameter (default 180) suggests recency logic, but the description fails to connect the dots clearly enough for an agent to correctly judge when to invoke this.
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%, meaning the schema provides no descriptions for limit and min_days. The description doesn't add meaning for these parameters either — 'limit' and 'min_days' are self-descriptive names, but the description doesn't clarify how min_days interacts with 'recent' or what a sensible limit is. With 0% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List strong relationships with no recent interaction' uses a specific verb (List) plus a resource (relationships/contacts), and distinguishes the scope ('strong relationships', 'no recent interaction'). It's clear what the tool does, though it doesn't explicitly distinguish it from sibling tools like graph_status or record_interaction. The purpose is specific enough to be useful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With 10 sibling tools including search_people, get_person, and graph_status, there's no clarity on edge cases (e.g., what defines 'strong relationship' or 'recent'), nor when a user should prefer this over other search/list tools. The description implies it's for relationship health queries but offers no exclusions or alternative guidance.
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. The description doesn't state whether this is a read-only path-finding operation, how paths are computed, whether it requires existing data/graph state, what happens when no path exists, or the depth limit behavior. For a tool that traverses a graph, the underlying mechanics and limitations are undocumented.
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 efficient sentence with zero wasted words. It conveys the core purpose clearly. However, given its brevity, it prioritizes compactness over the behavioral and parameter details that would add value.
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?
There is an output schema, which helps with return values, but this is a graph-traversal tool with three parameters at 0% schema coverage and no annotations. The description doesn't address the meaning of 'short', the depth semantics, what constitutes a path, graph prerequisites (e.g., does the graph need to be built first?), or failure behavior. For a non-trivial pathfinding tool, this is under-specified.
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 explains target_organization and from_person at a high level implicitly (the 'to/from' of the path). However, max_depth is entirely unexplained—its meaning, valid range, default behavior, and performance implications are absent from both schema and description. The description adds minimal semantic value beyond what the parameter names already convey.
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 ('Find'), the resource ('relationship paths'), the subject ('a person'), and the target ('anyone at a target organization'). It's specific enough to convey the core function. However, it doesn't explicitly distinguish from siblings like connect_people or search_people, though the name 'intro_path' front-loads the intent reasonably well.
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?
There's no explicit guidance on when to use this vs alternatives like search_people or connect_people. The description implies usage context ('relationship paths','intro') but doesn't name alternatives or exclusion criteria. With siblings that overlap thematically (connect_people, search_people), this is a meaningful gap.
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 full behavioral disclosure burden. It discloses that the tool is a search across multiple fields (a read/search operation implying non-destructive behavior), but provides no detail on result format, pagination, limit semantics, relevance ranking, or whether the query matches substring vs exact. For a search tool, ordering and match semantics are materially useful.
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 sentence that front-loads the verb and scope, with zero wasted words. It is adequately concise for a search tool, though it could not be considered exceptionally well-structured since all information is packed into one clause with no additional organizational structure.
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 an output schema (which explains return values, reducing description burden) and only 2 simple parameters. The description covers query semantics reasonably. However, it lacks guidance on match behavior, limit semantics, and result ordering, which for a search tool are relevant completeness gaps. Given its relative simplicity, it is minimally complete but not rich.
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 0%, so the description must compensate. It partially does by spelling out what the query can match against (name, organization, role, city, etc.), adding real meaning to the query parameter. However, it says nothing about the 'limit' parameter's behavior beyond what the schema's default of 20 implies, and provides no syntax/format hints for composing queries (e.g., free-text vs structured).
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 identifies the verb (search) and resource (people) and enumerates the search dimensions (name, organization, role, city, identifier, summary, fact). It signals this is a discovery/search operation distinct from targeted lookups like get_person. Lacks strong sibling differentiation (notably search_people vs get_person could be confused), but the enumerated search fields provide useful scope.
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 explicit guidance on when to use this vs alternatives. The sibling set includes get_person (likely a targeted lookup by ID), read_query, and write_query, but the description never clarifies the distinction. An agent might not know whether to use search_people or read_query for people queries, or when search_people is preferred over a direct get_person fetch.
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 only states 'Never guesses ambiguous names,' which is a constraint rather than describing behavior like whether connections are bidirectional, whether duplicate relationships are possible, whether existing relationships get overwritten, or the effects of the optional note/strength fields. For a mutation tool creating relationships in what appears to be a knowledge graph, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short at two sentences. The first sentence is front-loaded and clear. However, it's borderline under-specified rather than genuinely concise—the second sentence adds only a constraint. Given the tool's complexity (5 parameters, relationship semantics), slightly more length could be justified.
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?
There is an output schema, so return-value documentation isn't required. However, with 0% schema coverage, 5 parameters (3 required), and no annotations, the description is incomplete. It doesn't document valid 'kind' values, the strength semantics, or what a successful connection does to the graph. It's minimally functional but leaves important behavioral and parameter gaps for a tool with this complexity.
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 for undocumented parameters. It doesn't explain what 'kind' values are valid (relationship types), what strength means numerically, or what note is for. Neither the schema (bare titles like 'Kind', 'Person A', 'Strength') nor the description provide meaningful semantics for 3 of the 5 parameters. The description adds no parameter-level meaning beyond the 'ambiguous names' constraint.
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 clear purpose: 'Create a relationship between two existing people.' This uses a specific verb (create) with a clear resource (relationship between people). It distinguishes from siblings—search_people, get_person, remember_person all deal with individual people rather than relationships, while connect_people specifically targets the connection. However, it doesn't name the sibling relationships explicitly.
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 includes a partial usage guideline: 'Never guesses ambiguous names' implies the tool requires existing/unambiguous person references. However, it doesn't explain when to use this vs. record_interaction or add_fact (which could also capture relationships), nor does it specify prerequisites like whether people must already exist in the graph. The guidance is implied rather than explicit.
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 doesn't state whether this is a write/mutation operation, whether interactions are append-only, whether person_name must already exist (vs being created), data retention behavior, or any error conditions for invalid dates or unknown persons. Given the tool records data, this silent mutational behavior is a notable gap.
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, efficient sentence with zero wasted words. It front-loads the verb and resource and adds value by enumerating example interaction types. It's appropriately sized for the tool's simple scope.
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 4 params with 0% schema coverage, no annotations, and a mutation behavior. The output schema is present but the description still leaves significant ambiguity: what values are valid for 'channel', does 'person_name' need to pre-exist in the system (possibly relevant to sibling 'search_people'/'get_person'), and what date format does 'happened_on' expect? For a recording tool, these are important operational details missing from the description.
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 4 undocumented parameters. However, the description does enumerate interaction types (call, meeting, message, meal) which hints at what might go into 'channel' or 'summary'. It doesn't explain what format 'happened_on' takes, what values 'channel' accepts, or what 'person_name' semantics are (must it be an existing record?). With 0% coverage and no enrichment, score 3 is the fair mid-point.
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 ('Record') with a resource ('interaction') and enumerates the kinds of interactions it covers (call, meeting, message, meal, or other). It clearly distinguishes itself from sibling tools like 'add_fact' and 'remember_person' by focusing on dated interactions rather than general facts or people profiles.
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 ('record a dated interaction') but gives no explicit when-to-use or when-not-to-use guidance. Among siblings like 'add_fact', it's clear this is for temporal touchpoints vs. standalone facts, but the boundary isn't explicitly stated, and no alternatives are named.
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. 'No DDL or data changes' usefully discloses non-mutating behavior, and 'guarded' suggests protective limits. However, it doesn't elaborate on what 'guarded' entails (e.g., execution timeout, forbidden clauses, automatic row limits), what happens on violations, or how results are returned. It adds some value beyond what the schema provides but lacks depth.
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?
Two sentences, no filler. The description is efficiently front-loaded with the core purpose followed by the safety disclaimer. Every word earns its place, though the brevity leaves behavioral detail unaddressed.
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 a free-form query executor (high complexity in terms of what the agent might write), with no annotations and 0% schema description coverage. While output_schema exists (helps with return understanding), the description leaves significant unknowns: query language, 'guarded' semantics, max_rows behavior, and error handling. Given the complexity, the description is under-specified, though the presence of an output schema earns it a mid score.
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 for the two parameters (query, max_rows). The description mentions 'query' implicitly by 'advanced graph analysis' but provides no guidance on query syntax, language (SQL? Cypher?), or how max_rows is enforced. With zero schema coverage, the description fails to explain parameter meaning or usage, which is a significant 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 description states it runs a 'guarded SELECT' for 'advanced graph analysis', which is a specific verb+resource with a clear scope. It distinguishes from siblings like write_query (clearly the write counterpart). However, it doesn't name the specific alternative or elaborate enough to fully disambiguate from other query-related tools.
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 read-only usage ('No DDL or data changes') and mentions 'guarded', giving some context. However, it does not explicitly state when to use this vs alternatives, nor does it specify the exact safety constraints of 'guarded' (e.g., is there a timeout? a row cap enforced automatically? a read replica?). The guidance is implied but not fully explicit.
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 full disclosure burden. It indicates a read-only check operation but doesn't state error behavior (e.g., what happens if the graph is disconnected, whether it throws, returns partial results), rate limits, or what specific counts are returned. This is a read operation, but minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, the phrase 'graph connection' is slightly ambiguous in context (connection status vs. connectivity diagnostics), and 'record counts' could be more specific about what records count against.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, complete enough for a diagnostic check. The output schema exists and presumably documents the return structure. However, the description could clarify what error/status signaling occurs if the graph is unreachable, and whether record counts represent the full graph or some subset.
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 tool has zero parameters, so the schema provides nothing to document. With no params, the baseline is 4 per the rubric. The description clearly conveys what the tool returns (record counts) without needing parameter 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 states a clear purpose: check graph connection and return record counts. It uses a specific verb ('check') and resource ('graph'), distinguishes its diagnostic function from the sibling tools which perform search, retrieval, and mutation operations on graph data.
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 'check' verb implies a diagnostic/health-check use case. Context around when to run this (e.g., before queries, after connection issues, to validate the graph is responsive) is absent but somewhat implicit given the phrasing and zero parameters.
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 burden of behavioral disclosure. It discloses safety guards (WHERE requirement, DDL blocked) which indicate operational protections. However, it doesn't disclose what happens on failure, whether this is a mutation with no rollback, any permissions/auth requirements, or what the output shape is. The safety restrictions give some transparency but leave gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with zero wasted words. Every clause carries information about allowed operations and constraints. It's ideal front-loaded specification that an agent can parse quickly.
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 tool with 1 free-form string parameter, an output schema, and no annotations, the description covers the essential constraint (which statement types are allowed) but doesn't explain return behavior. Given it has an output schema, the return format is presumably structured elsewhere. The missing piece is parameter format guidance—what SQL dialect, escaping expectations, multi-statement handling—which would help complete the picture for a query execution tool.
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 schema has 0% description coverage and only one parameter (query), which is a free-form string. The description does not elaborate on the query parameter's format, escaping requirements, or valid syntax beyond the INSERT/UPDATE/DELETE restriction. With zero schema coverage, the description should compensate by explaining how to format the query string, but it provides no such guidance.
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 runs INSERT/UPDATE/DELETE queries with specific verbs indicating the write operation. It distinguishes from sibling 'read_query' by explicitly stating it handles writes (INSERT/UPDATE/DELETE) while implying read_query is for reads, though it doesn't name the sibling explicitly. The resource is a database query, and the specific operation types are named clearly.
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 explicit usage constraints: UPDATE/DELETE require WHERE, and DDL is blocked. This tells the agent what queries are permissible. However, it doesn't explicitly state when to prefer this over read_query or other write-alternatives in the sibling list, though the INSERT/UPDATE/DELETE scope plus the 'DDL blocked' guard gives clear boundaries.
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 annotations are provided, so the description carries the full burden. The description discloses a key behavioral trait: it returns candidates instead of guessing when ambiguous, which is genuinely valuable and non-obvious behavior. It doesn't cover what the output looks like, but with an output schema present, the bar is somewhat lower. Reads clearly as non-destructive given 'Get'.
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 sentences, both information-dense. The first states the purpose, the second adds the critical ambiguity-handling behavior. Zero wasted words.
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 single-parameter lookup tool with an output schema present, this is reasonably complete. The ambiguity-return behavior is disclosed, and the output schema presumably documents the return format. Could benefit from mentioning what 'full record' includes, but that's likely captured in the output schema, so not a major gap.
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% with a single 'name' parameter. The description doesn't add any specifics about the name format (partial vs exact, case sensitivity, etc.), though the ambiguity note hints that partial-matching may occur. The parameter is simple enough that the baseline isn't severely harmed, but no additional semantic value is added beyond the schema.
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?
Clear verb+resource: 'Get one person's full record.' The differentiation from siblings is implied ('one person' vs search_people which presumably returns multiple). However, it doesn't explicitly distinguish from search_people, and the alternative to look up people is clearly search_people. The ambiguity-return behavior ('Returns candidates...') adds useful scoping.
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 states 'Get one person's full record' implying this is for a single known person, and the ambiguity note suggests when the exact person is unclear it returns candidates. However, it doesn't explicitly say when to use this vs search_people, nor does it state when-not-to-use it. The context is somewhat clear (single record lookup) but lacks explicit alternatives.
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 the important guardrail behavior: refusing duplicates and conflicting overwrites, and requiring user confirmation before proceeding. This is significant behavioral insight. However, it doesn't disclose what gets destroyed on overwrite, whether the operation is idempotent, or any persistence details.
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?
Three sentences, no filler. The core purpose is stated in one line, then the guardrail behavior follows. It's front-loaded with the verb+resource. Could arguably merge or elaborate slightly, but overall it's economical and earns each sentence.
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?
Despite having an output schema and only 1 required param, the 13-parameter tool with 0% schema coverage needs more. The description explains the confirmation workflow well but says nothing about what the tool returns, how fact_key/fact_value interact with the person-record fields, or whether there are constraints on the data (format, length). For a 13-param mutation tool, this is marginally adequate but has clear 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 coverage is 0%, so the description has the burden to explain parameters. It covers confirmed_new and overwrite semantics via the guardrail text, but the remaining 11 parameters (city, email, phone, country, summary, fact_key, full_name, fact_value, current_org, current_role, linkedin_url) are entirely undocumented. The description explains the two boolean toggles but nothing about the data fields themselves. With 0% coverage, the baseline 3 is appropriate but the description falls short of fully compensating.
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 clear verb+resource: "Create or update a person from conversation." This distinguishes it from siblings like get_person (read), search_people (search), and add_fact (adds facts to existing person). It's clear and specific, though it could more explicitly differentiate from add_fact which also relates to person data.
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 explicit guidance on the guarded workflow: "By default this refuses similar-name duplicates and conflicting overwrites. Ask the user, then retry with confirmed_new or overwrite only after they decide." This tells the agent when to use confirmed_new vs overwrite parameters, which is valuable behavioral guidance. However, it doesn't cover when to prefer add_fact or update via other tools.
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:

[![people-memory-mcp MCP server](https://glama.ai/mcp/servers/michelgrolet/people-memory-mcp/badges/card.svg)](https://glama.ai/mcp/servers/michelgrolet/people-memory-mcp)

Score Badge

Copy to your README.md:

[![people-memory-mcp MCP server](https://glama.ai/mcp/servers/michelgrolet/people-memory-mcp/badges/score.svg)](https://glama.ai/mcp/servers/michelgrolet/people-memory-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/michelgrolet/people-memory-mcp'

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