Provides optional cloud storage backend using Cloudflare R2 for storing and managing dynamic review records with user-defined schemas, enabling production deployment with R2 as an alternative to local filesystem storage.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Record MCP Server add a coffee review with nutty flavor, strong aroma, medium acidity, and rating 8.5"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for storing and managing dynamic review records with user-defined schemas. Perfect for organizing reviews of coffee, whisky, wine, or any other category you can think of!
Dynamic Schemas: Create review types with custom fields on-the-fly
Flexible Storage: Local filesystem (dev) or Cloudflare R2 (production)
Type-Safe: Built with TypeScript and runtime validation
Extensible: Add new fields to existing review types
Easy Migration: Switch from local to cloud storage with one environment variable
Related MCP server: Content Manager MCP Server
# Install dependencies
npm install
# Build the project
npm run buildCopy the example environment file:
cp .env.example .envFor local development (default):
STORAGE_PROVIDER=local
LOCAL_DATA_PATH=./dataFor production with Cloudflare R2:
STORAGE_PROVIDER=r2
R2_ACCOUNT_ID=your_account_id
R2_ACCESS_KEY_ID=your_access_key
R2_SECRET_ACCESS_KEY=your_secret_key
R2_BUCKET_NAME=review-recordsDevelopment mode (with auto-reload):
npm run devProduction mode:
npm run build
npm startnpm testThe server provides the following MCP tools:
list_review_typesList all review types with their schemas and record counts.
Parameters: None
Example Response:
{
"types": [
{
"name": "coffee",
"schema": [
{ "name": "flavor", "type": "string" },
{ "name": "aroma", "type": "string" },
{ "name": "acidity", "type": "string" }
],
"recordCount": 5,
"createdAt": "2025-11-16T10:00:00Z",
"updatedAt": "2025-11-16T12:00:00Z"
}
]
}get_review_typeGet detailed information about a specific review type including all records.
Parameters:
typeName (string): Name of the review type
Example:
{
"typeName": "coffee"
}add_review_typeCreate a new review type with a custom schema.
Parameters:
name (string): Name of the review type (e.g., "coffee", "whisky")
fields (array): Array of field definitions
Supported Field Types:
string: Text values
number: Numeric values
boolean: True/false values
date: ISO 8601 date strings
Example:
{
"name": "coffee",
"fields": [
{ "name": "flavor", "type": "string" },
{ "name": "aroma", "type": "string" },
{ "name": "acidity", "type": "string" },
{ "name": "rating", "type": "number" }
]
}add_field_to_typeAdd a new field to an existing review type's schema.
Parameters:
typeName (string): Name of the review type
fieldName (string): Name of the new field
fieldType (string): Type of the field (string, number, boolean, date)
Example:
{
"typeName": "coffee",
"fieldName": "body",
"fieldType": "string"
}add_review_recordAdd a new review record to a type.
Parameters:
typeName (string): Name of the review type
data (object): Review data matching the type's schema
Example:
{
"typeName": "coffee",
"data": {
"flavor": "nutty",
"aroma": "strong",
"acidity": "medium",
"rating": 8.5
}
}// 1. Create a new review type
await mcp.callTool("add_review_type", {
name: "whisky",
fields: [
{ name: "taste", type: "string" },
{ name: "age", type: "number" },
{ name: "peated", type: "boolean" },
{ name: "tasted_on", type: "date" }
]
});
// 2. Add a review
await mcp.callTool("add_review_record", {
typeName: "whisky",
data: {
taste: "smoky and complex",
age: 12,
peated: true,
tasted_on: "2025-11-16T10:00:00Z"
}
});
// 3. Add more fields later
await mcp.callTool("add_field_to_type", {
typeName: "whisky",
fieldName: "region",
fieldType: "string"
});
// 4. List all types and their data
const result = await mcp.callTool("list_review_types", {});record-mcp/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── types.ts # TypeScript type definitions
│ ├── storage/
│ │ ├── interface.ts # Storage provider interface
│ │ ├── local.ts # Local file system storage
│ │ ├── r2.ts # Cloudflare R2 storage
│ │ └── factory.ts # Storage provider factory
│ ├── tools/
│ │ ├── list-types.ts # List and get review types
│ │ ├── add-type.ts # Create new review type
│ │ ├── add-field.ts # Add field to type
│ │ └── add-record.ts # Add review record
│ └── utils/
│ └── validation.ts # Schema and data validation
├── data/ # Local storage (when using local provider)
│ ├── types/
│ │ ├── coffee.json
│ │ └── whisky.json
│ └── index.json
└── tests/
├── storage.test.ts # Storage provider tests
└── tools.test.ts # MCP tools testsThe server uses a storage abstraction layer that allows easy switching between local files and Cloudflare R2:
Local Storage (Development): Uses Node.js fs/promises to store JSON files
R2 Storage (Production): Uses AWS S3-compatible API to store in Cloudflare R2
Both providers implement the same StorageProvider interface, making migration seamless.
Each review type is stored as a separate JSON file:
{
"name": "coffee",
"schema": [
{ "name": "flavor", "type": "string" },
{ "name": "aroma", "type": "string" }
],
"records": [
{
"id": "1234567890-abc123",
"data": {
"flavor": "nutty",
"aroma": "strong"
},
"createdAt": "2025-11-16T10:00:00Z"
}
],
"createdAt": "2025-11-15T09:00:00Z",
"updatedAt": "2025-11-16T10:00:00Z"
}When you're ready to move to production:
Set up your Cloudflare R2 bucket
Update your .env file with R2 credentials
Change STORAGE_PROVIDER=r2
Restart the server
Optional: Use a migration script to copy existing data:
// Copy all local files to R2
const localStorage = new LocalStorageProvider('./data');
const r2Storage = new R2StorageProvider(r2Config);
const types = await localStorage.listTypes();
for (const typeName of types) {
const data = await localStorage.readType(typeName);
await r2Storage.writeType(typeName, data);
}The server provides comprehensive validation:
Type Names: Alphanumeric, hyphens, and underscores only
Field Types: Must be one of: string, number, boolean, date
Required Fields: All schema fields must be present in records
Extra Fields: Records cannot have fields not in the schema
Type Checking: Field values must match their declared types
All tools return structured error messages:
{
"error": "Review type \"coffee\" already exists"
}Common errors:
Duplicate type names
Duplicate field names
Missing required fields in records
Type mismatches
Invalid type/field names
npm run buildnpm run watchRun all tests:
npm testRun specific test file:
tsx tests/storage.test.ts
tsx tests/tools.test.tsMIT
Contributions welcome! Please ensure tests pass before submitting PRs.
For issues or questions, please open a GitHub issue.
Add a new field to an existing review type schema
| Name | Required | Description | Default |
|---|---|---|---|
| typeName | Yes | Name of the review type to modify | |
| fieldName | Yes | Name of the new field | |
| fieldType | Yes | Type of the new field |
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. While 'Add' implies a write/mutation operation, the description doesn't specify permissions required, whether the change is reversible, potential side effects (e.g., impact on existing records), or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in 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.
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 without unnecessary words. It is front-loaded and every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical behavioral details (e.g., permissions, reversibility) and doesn't explain what the tool returns or potential errors. For a tool that modifies schemas, this level of documentation is inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters clearly documented in the schema itself (typeName, fieldName, fieldType with enum values). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add a new field') and target resource ('to an existing review type schema'), distinguishing it from sibling tools like 'add_review_type' (which creates entire types) and 'get_review_type'/'list_review_types' (which are read-only). It precisely communicates the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when modifying an existing review type schema, but it doesn't explicitly state when to use this tool versus alternatives (e.g., when to use 'add_review_type' for creating a new type instead). No exclusions or prerequisites are mentioned, leaving some ambiguity about appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new review record to a type
| Name | Required | Description | Default |
|---|---|---|---|
| typeName | Yes | Name of the review type | |
| data | Yes | Review data matching the type schema |
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. While 'Add' implies a write/mutation operation, the description doesn't address important behavioral aspects like whether this requires specific permissions, what happens on duplicate records, whether the operation is idempotent, or what the response looks like. For a mutation tool with zero annotation coverage, this represents a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core functionality and wastes no space on redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what constitutes a successful operation, what errors might occur, how to interpret results, or how this tool relates to the sibling tools in the ecosystem. The agent would struggle to use this tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so both parameters are already documented in the schema. The description adds minimal value beyond what the schema provides - it mentions 'type' which relates to 'typeName' and 'review data' which relates to 'data', but doesn't provide additional context about format requirements, validation rules, or example usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a new review record') and target resource ('to a type'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its siblings like 'add_review_type' or 'add_field_to_type', which would require explaining that this tool adds data records rather than schema definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'add_review_type' (which creates review types) or 'add_field_to_type' (which modifies type schemas). There's no mention of prerequisites, sequencing, or contextual factors that would help an agent choose between these related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new review type with a custom schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the new review type (e.g., "coffee", "whisky") | |
| fields | Yes | Array of field definitions for the schema |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks behavioral details. It states 'Create' implying a mutation, but doesn't disclose permissions needed, whether creation is idempotent, error handling, or rate limits. This is inadequate for a tool that likely modifies system state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after creation (e.g., returns an ID, error cases), behavioral traits, or usage context, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal value beyond the schema by hinting at a 'custom schema' context, but doesn't provide additional semantics like examples of field definitions or naming constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new review type'), specifying it involves a custom schema. It distinguishes from siblings like 'add_field_to_type' (modifies existing) and 'add_review_record' (adds data), but doesn't explicitly contrast with 'get_review_type' or 'list_review_types'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. It doesn't mention prerequisites (e.g., if review types must be unique), when not to use it (e.g., for updating existing types), or refer to siblings like 'add_field_to_type' for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific review type including all records
| Name | Required | Description | Default |
|---|---|---|---|
| typeName | Yes | Name of the review type to retrieve |
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 tool retrieves information, implying it's a read-only operation, but doesn't clarify if it requires authentication, has rate limits, returns paginated results, or what 'all records' entails (e.g., format, size). This leaves significant gaps for a tool with potential data retrieval complexities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Get detailed information'). It avoids redundancy and wastes no words, though it could be slightly more structured by explicitly separating purpose from scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations and no output schema, the description is incomplete. It mentions retrieving 'all records' but doesn't explain the return format, data structure, or potential limitations (e.g., if 'all records' implies a large dataset). Given the lack of structured context, more detail on behavior and output is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'typeName' clearly documented as 'Name of the review type to retrieve'. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific review type'), making the purpose understandable. It distinguishes from siblings like 'list_review_types' by focusing on a single type rather than listing all types. However, it doesn't explicitly differentiate from 'add_review_record' or 'add_field_to_type' in terms of read vs write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or compare it to siblings like 'list_review_types' for broader queries or 'add_review_type' for creation. Usage is implied only by the action described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all review types with their schemas and record counts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves—e.g., whether it's read-only, if it requires authentication, how data is returned (e.g., pagination, format), or potential side effects. This is a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff. It's front-loaded with the core action and includes specific details (schemas and record counts) that add value, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is adequate but not complete. It lacks behavioral context (e.g., return format, safety profile) that would be helpful for an agent, especially with no annotations. However, for a list operation with no inputs, it meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%, so there's no need for parameter documentation in the description. The description appropriately focuses on the tool's purpose without redundant parameter details, earning a baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all review types') and specifies what information is included ('with their schemas and record counts'), which goes beyond just restating the name. However, it doesn't differentiate this tool from its sibling 'get_review_type', which appears to serve a similar purpose but might fetch a single type instead of listing all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_review_type'. It doesn't mention prerequisites, exclusions, or specific contexts for usage, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
add_field_to_typeadd_review_recordadd_review_typeget_review_typelist_review_typesEach tool has a clearly distinct purpose: add_field_to_type modifies schemas, add_review_record creates data entries, add_review_type creates new types, get_review_type retrieves detailed type information, and list_review_types provides an overview. There is no overlap or ambiguity between these operations.
All tool names follow a consistent verb_noun pattern (e.g., add_field_to_type, get_review_type, list_review_types) with clear, descriptive actions and targets. The naming is uniform and predictable throughout the set.
With 5 tools, this server is well-scoped for managing review types and records. The count is appropriate, covering core operations without being overly sparse or bloated, and each tool serves a necessary function in the domain.
The tool set provides good coverage for creating and retrieving review types and records, but lacks update and delete operations (e.g., update_review_type, delete_review_record). This minor gap might require workarounds but does not severely hinder core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
AI-native Git-based CMS for Astro. Create and publish content in the browser, without learning git.
No-code databases, forms, portals and AI sites. Manage records and automation via natural language.
No-code databases, forms, portals and AI sites. Manage records and automation via natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sanggggg/record-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
