tidbits-memory

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity: create_memory, create_voter_id, downvote_memory, get_memories, list_memory, remove_memory, unvote_memory, and upvote_memory. The actions (create, get, list, remove, upvote, downvote, unvote) and targets (memory, voter_id) are well-defined and non-overlapping.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case (e.g., create_memory, downvote_memory, get_memories). The naming is predictable and uniform across all eight tools, with no deviations in style or convention.
Tool Count5/5
With 8 tools, the count is well-scoped for a memory/voting system. Each tool serves a specific function in managing memories and votes, and none appear redundant or unnecessary for the server's purpose.
Completeness5/5
The tool set provides complete coverage for the memory and voting domain: CRUD operations (create, get/list, remove), voting lifecycle (upvote, downvote, unvote), and voter management (create_voter_id). There are no obvious gaps, and agents can handle all core workflows without dead ends.
Average 3.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns the created memory with its ID, which is helpful, but fails to address critical aspects like authentication requirements, rate limits, error conditions, or whether this is a persistent write operation. For a creation tool with zero annotation coverage, this leaves significant 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 with just two short sentences that are front-loaded with the core purpose. Every word earns its place, and there's no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return value documentation) but no annotations and poor schema coverage, the description is minimally adequate for understanding the basic operation. However, for a creation tool with multiple parameters, it should provide more context about parameter usage and behavioral expectations to be truly complete.
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?
With 0% schema description coverage for 4 parameters (1 required, 3 optional), the description provides no information about parameter meanings, formats, or constraints. It doesn't explain what 'content', 'creator', 'tags', or 'voter_id' represent or how they should be used, failing to compensate for the schema's lack of 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 clearly states the action ('Create a new memory/tidbit') and the resource ('memory'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_memory' or 'remove_memory' beyond the basic verb distinction, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_memory' or 'remove_memory'. There's no mention of prerequisites, context, or specific scenarios where creation is appropriate versus other operations on memories.
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 states the action ('Remove a prior vote') but doesn't clarify whether this is a destructive operation, what permissions are required, if it's reversible, or what happens if the vote doesn't exist. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place in conveying the essential purpose.
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 2 parameters, no annotations, and an output schema (which handles return values), the description is minimally adequate. It states the basic action but lacks details on behavioral traits, parameter meanings, and usage context. The output schema reduces the need to describe returns, but the description should do more for a mutation 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?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'voter_id' but doesn't explain what 'memory_id' represents or the format/constraints for either parameter. It adds minimal semantic value beyond naming one parameter, failing to compensate for the coverage 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 clearly states the action ('Remove a prior vote') and the target resource ('from a memory by voter_id'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'upvote_memory' and 'downvote_memory' by specifying removal rather than addition. However, it doesn't explicitly contrast with 'remove_memory' (which likely deletes the entire memory), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a vote must exist first), nor does it differentiate from sibling tools like 'remove_memory' or explain the relationship with 'upvote_memory'/'downvote_memory'. The agent must infer usage from context alone.
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 mentions sorting by votes descending, which is useful, but fails to cover critical aspects like whether this is a read-only operation (implied by 'list' but not explicit), pagination behavior, rate limits, authentication needs, or what the output contains. This leaves significant gaps for a tool with potential complexity.
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, efficient sentence that front-loads the key action and sorting detail with zero wasted words. It is appropriately sized for a simple listing tool, making it easy for an agent to 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?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is incomplete. It covers the sorting behavior but misses usage guidelines, parameter details, and behavioral traits. The presence of an output schema reduces the need to explain return values, but the description still lacks sufficient context for safe and effective 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?
The schema description coverage is 0%, so the description must compensate. It implicitly references 'votes' as a sorting criterion, which relates to the 'order_by' parameter, but doesn't explain the 'limit' parameter or provide details on parameter formats or constraints. This adds minimal value beyond the schema, meeting the baseline for low coverage without fully addressing the gaps.
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 action ('List all memories') and specifies the sorting method ('sorted by votes descending'), which distinguishes it from siblings like 'get_memories' (which might have different filtering) and 'create_memory' (a write operation). However, it doesn't explicitly differentiate from 'get_memories' in terms of scope or filtering, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_memories' or 'create_memory'. It lacks context such as use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the name and description alone.
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 burden. 'Remove' implies a destructive mutation, but the description doesn't disclose whether this is permanent, requires specific permissions, has side effects, or what happens on success/failure. This is inadequate for a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and uses minimal words to convey the essential 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?
Given the tool has an output schema (which handles return values), the description's main gaps are behavioral transparency and parameter semantics. For a destructive operation with no annotations and 0% schema coverage, it's minimally adequate but leaves significant questions unanswered about how the tool behaves.
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 mentions 'by id', which adds meaning by indicating the parameter identifies a specific memory, but doesn't explain the ID format, source, or constraints. This provides some value but doesn't fully address the coverage 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 clearly states the verb ('remove') and resource ('memory'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'downvote_memory' or 'unvote_memory', which might also involve memory modification, so it doesn't reach the highest clarity level.
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 alternatives. With siblings like 'downvote_memory', 'unvote_memory', and 'get_memories', the description offers no context about when removal is appropriate versus other memory operations.
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 mentions the 'voter_id' parameter for session-based voting enforcement, which adds some context about behavior, but it lacks details on effects (e.g., does upvoting increment a score, is it reversible, what permissions are needed), response format, or error handling, leaving significant 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 a single, efficient sentence that front-loads the core action ('Upvote a memory') and adds necessary context without waste. Every word earns its place, making it highly concise and well-structured.
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's moderate complexity (2 parameters, mutation action) and the presence of an output schema (which reduces need to explain returns), the description is partially complete. It covers the basic action and a key parameter behavior, but without annotations and with low schema coverage, it should do more to explain effects, errors, or usage nuances.
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 the purpose of 'voter_id' ('to enforce one vote per session'), adding meaning beyond the schema, but it doesn't address 'memory_id' or provide details on parameter formats, constraints, or interactions, resulting in incomplete coverage.
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 'upvote' and resource 'a memory', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'downvote_memory' or 'unvote_memory' beyond the obvious directional difference, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'voter_id to enforce one vote per session', which suggests context for when to provide this parameter, but it doesn't explicitly state when to use this tool versus alternatives like 'downvote_memory' or 'unvote_memory', nor does it provide prerequisites or exclusions.
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 full burden. It states the tool generates a 'unique voter_id', implying creation, but doesn't disclose behavioral traits like whether this is idempotent, requires specific permissions, or how uniqueness is enforced. The description is minimal and lacks operational context.
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, efficient sentence that directly states the tool's purpose with no wasted words. It's appropriately sized and front-loaded, making it easy to understand 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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, as a creation tool with no annotations, it lacks details on behavioral aspects like idempotency or session-specific constraints, leaving some gaps in completeness.
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 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description appropriately doesn't discuss non-existent parameters.
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 action ('Generate') and resource ('new unique voter_id'), specifying it's for 'this agent session'. It doesn't explicitly differentiate from siblings, but since no sibling tools handle voter IDs, the purpose is sufficiently clear.
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 mentions 'for this agent session', which provides some context, but offers no guidance on when to use this tool versus alternatives or prerequisites. There's no explicit when/when-not usage advice.
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 mentions the 'voter_id' for vote enforcement, adding some context, but lacks details on permissions, rate limits, or what happens on downvoting (e.g., effects on memory visibility or scoring). This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and adds necessary context without waste. Every word earns its place, making it appropriately sized and well-structured.
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's complexity (a mutation with 2 parameters), no annotations, and an output schema present (which handles return values), the description is minimally adequate. It covers the basic action and key parameter context but lacks behavioral details like permissions or side effects, leaving gaps in completeness.
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 schema provides no parameter details. The description adds meaning by explaining that 'voter_id' enforces 'one vote per session,' which clarifies its purpose beyond the schema. However, it doesn't cover 'memory_id' or provide full compensation for the coverage 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 clearly states the action ('downvote') and target resource ('a memory'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'upvote_memory' or 'unvote_memory' beyond the directional difference, missing explicit distinction.
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 by mentioning 'voter_id to enforce one vote per session,' suggesting when to use this parameter, but it doesn't explicitly state when to choose this tool over alternatives like 'upvote_memory' or 'unvote_memory,' or any prerequisites.
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 mentions that a new voter_id is generated if not provided, which adds some context about the tool's behavior. However, it fails to describe other key traits such as whether this is a read-only operation, any rate limits, authentication needs, or what the output looks like (though an output schema exists, the description doesn't hint at return values).
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, well-structured sentence that efficiently conveys the tool's purpose and key behavioral detail without any wasted words. It is front-loaded with the main action and follows with important context.
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 1 parameter with low schema coverage and an output schema exists (which reduces the need to describe return values), the description provides basic purpose and some parameter context. However, as a tool with no annotations, it lacks details on behavioral traits like safety or performance, making it incomplete for fully informed 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?
The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic information. The description adds meaning by explaining that 'voter_id' is optional and if omitted, a new one is generated for use in subsequent votes, which clarifies its purpose beyond the schema. However, it doesn't detail the format or constraints of 'voter_id', leaving some gaps.
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 action ('Get') and resource ('list of memories'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_memory' which might serve a similar function, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining that if 'voter_id' is not provided, a new one is generated for subsequent votes, suggesting context for when to use this parameter. But it lacks explicit guidance on when to choose this tool over alternatives like 'list_memory' or 'create_voter_id', leaving room for ambiguity.
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:

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

Score Badge

Copy to your README.md:

[![tidbits-memory MCP server](https://glama.ai/mcp/servers/brkhrdt/tidbits-memory/badges/score.svg)](https://glama.ai/mcp/servers/brkhrdt/tidbits-memory)

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/brkhrdt/tidbits-memory'

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