Skip to main content
Glama
The-Sequence

Chronicle

by The-Sequence
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Chronicle

Chronicle is a local-first, provenance-preserving personal archive with a read-only Model Context Protocol (MCP) gateway. It preserves files and supported AI conversation exports, derives evidence-linked candidate memories with local models, and retrieves only the context needed for a particular question.

Chronicle is an early-stage research prototype. It is not a backup replacement, medical system, or authority on a person's identity.

Why Chronicle exists

Long-term AI memory must retain useful detail without sending an entire digital life to every model on every request. Chronicle separates the work:

  1. Original inputs are archived with hashes, timestamps, and provenance.

  2. Apple's on-device model performs fast routing when available.

  3. Qwen through LM Studio proposes detailed, evidence-cited memories.

  4. Deterministic validators reject unsupported, malformed, or unsafe claims.

  5. A read-only MCP gateway provides bounded search-then-fetch retrieval.

Derived claims remain reviewable candidates linked to their original evidence; model output does not automatically become an authoritative profile.

Related MCP server: suasor

Current capabilities

  • Content-addressed local archive with SHA-256 integrity checks

  • Immutable versions when source files change

  • SQLite full-text search and provenance metadata

  • Lossless import of supported Claude conversation exports

  • Deterministic, turn-preserving conversation windows

  • Apple Foundation Models routing on compatible Macs

  • Resumable Qwen candidate extraction through LM Studio

  • Exact evidence-quote and speaker-authority validation

  • Sensitive-topic escalation and identifier blocking

  • Progress reporting and repeated-failure quarantine

  • Page-aware PDF memory with bounded retrieval

  • Read-only MCP overview, search, and exact-fetch tools

  • Optional delegated Google and Microsoft read connectors

Chronicle contains no send, delete, shell, or computer-control MCP tools.

Requirements

Core:

  • Python 3.11 or newer

  • uv for installation

  • macOS, Linux, or Windows for the archive and MCP gateway

Reference configuration matching the original development machine:

  • Apple-silicon Mac with Apple Intelligence enabled

  • macOS with the Foundation Models framework available

  • Xcode/Swift toolchain capable of building the helper package

  • LM Studio local server on 127.0.0.1:1234

  • qwen/qwen3-14b, MLX 4-bit, with an 8,192-token context

The Apple helper is optional. It checks SystemLanguageModel.default at runtime. Chronicle does not access Siri's private system-wide index.

Installation

git clone https://github.com/The-Sequence/chronicle.git
cd chronicle
uv sync --extra dev
cp .env.example .env
./chronicle system-status

The chronicle wrapper uses the project virtual environment. You may use uv run personal-context-archive instead.

Build the optional Apple helper

cd apple-helper
swift build -c release
cd ..
./chronicle system-status

If unavailable, confirm that the device supports Apple Intelligence, it is enabled, and its model has finished downloading.

Configure LM Studio

  1. Install LM Studio.

  2. Download qwen/qwen3-14b in MLX 4-bit format.

  3. Load the model with context length 8192.

  4. Open Developer → Local Server.

  5. Use port 1234; leave Serve on Local Network disabled.

  6. Start the server.

Use these .env values:

PCG_LM_BASE_URL=http://127.0.0.1:1234/v1
PCG_LM_MODEL=qwen/qwen3-14b
PCG_LM_API_KEY=lm-studio
PCG_TRIAGE_MAX_CHARS=24000

The placeholder key is used because the compatible request format expects one. If LM Studio authentication is enabled, use a real local token and never commit it.

Safe first run

Do not begin with a home directory. Test a small disposable folder:

./chronicle scan "/absolute/path/to/small-test-folder"
./chronicle work-status
./chronicle search "sample topic"

Private runtime data defaults to ./personal-archive. That directory, .env, exports, caches, and model artifacts are excluded from Git.

Before using valuable data:

  • use FileVault or another encrypted volume;

  • back up chronicle.sqlite3 and the objects directory;

  • keep LM Studio bound to localhost;

  • explicitly allowlist source folders;

  • never configure an entire home directory as a local root.

Import an AI conversation

./chronicle import-conversations "/path/to/conversation.json"
./chronicle conversation-status
./chronicle search-conversations "topic or decision"

Build and route deterministic windows:

./chronicle plan-conversation 1 --limit 12
./chronicle build-conversation-windows 1
./chronicle route-conversation 1 --limit 10
./chronicle conversation-route-status 1

Run bounded detailed extraction:

./chronicle preview-extraction 1
./chronicle extract-conversation 1 --max-segments 1
./chronicle extraction-progress 1
./chronicle candidate-status 1
./chronicle candidates 1 --limit 100

partial means valid candidates were checkpointed while other proposals were rejected. After three validation failures, a segment is visibly quarantined so later segments can continue; it is not silently treated as successful.

Run the read-only MCP gateway

uv run personal-context-gateway

Development inspection:

uv run mcp dev src/context_gateway/server.py

Remote deployment requires HTTPS and per-client OAuth authorization in front of /mcp. Give each client an independent, revocable credential. Never put bearer secrets in URLs.

Optional provider access

Start read-only with delegated permissions:

  • Gmail: gmail.readonly

  • Google Calendar: calendar.events.readonly

  • Outlook mail: Mail.Read

  • Microsoft Calendar: Calendars.Read

  • Identity: openid profile offline_access User.Read

Teams is deferred because school and workplace tenants often require administrator approval. Chronicle does not bypass tenant policy.

Privacy model

The public repository contains no archive, extracted memories, conversations, OAuth tokens, model files, machine-specific paths, or private Git history.

  • Source text is untrusted data, never model instructions.

  • Filesystem reads are restricted to explicit roots.

  • Symlink escapes, traversal, oversized files, and disallowed extensions fail.

  • MCP responses are bounded and provenance-rich.

  • Raw sources remain authoritative.

  • Derived memories retain evidence and extraction-version metadata.

  • Sensitive identifiers are blocked from derived memory.

  • Failures remain visible, retryable, or quarantined.

See SECURITY.md.

Tests

uv run pytest -q

Tests use synthetic fixtures only and require no personal files or accounts.

Status

Chronicle is under active development. Planned work includes candidate review, contradiction-aware consolidation, compact low-token retrieval summaries, authenticated remote MCP deployment, and additional approved importers.

Attribution

Chronicle is independent and is not affiliated with Apple, Anthropic, LM Studio, Qwen, Sentient OS, OpenAI, OpenClaw, or the MCP maintainers.

Publicly documented local-first and staged-memory patterns—particularly Sentient OS—informed the architecture. Chronicle's code, prompts, schemas, and tests were independently implemented. See ACKNOWLEDGMENTS.md and THIRD_PARTY_NOTICES.md.

License

Released under the MIT License.

Available Tools

7 tools
fetchA
Read-only

Fetch one exact item returned by search. Never accepts raw paths or URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only and non-destructive. The description adds the constraint that raw paths/URLs are rejected, which is useful operational context, but does not describe error behavior, auth needs, or output.

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 short sentences, front-loaded with the core purpose. No filler words; every phrase adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter fetch with no output schema, the description adequately covers the main semantics and usage constraints. It lacks output details but is sufficient given the low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage for the 'id' parameter. The description implies id is a search result identifier and not a raw path/URL, adding some meaning, but doesn't specify the format or how to obtain it. Baseline 3 is appropriate as the description partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches one exact item returned by search, with a specific verb and resource. It distinguishes from siblings like fetch_document_section by focusing on search results and explicitly excluding raw paths/URLs.

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?

Provides clear context: use when you have a search result item, and explicitly states what it never accepts (raw paths/URLs). Does not name alternatives explicitly, but the exclusion gives a strong usage signal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetch_document_sectionA
Read-only

Fetch one exact detailed memory section returned by search_document_memory.

ParametersJSON Schema
NameRequiredDescriptionDefault
section_idYes

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that the section is 'exact' and 'detailed', suggesting it returns full content rather than a snippet. However, it doesn't disclose behavior for invalid or missing section IDs, error handling, or rate limits. It adds some context beyond annotations but not rich behavioral detail.

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 12-word sentence that is front-loaded with the verb 'Fetch' and contains no filler. Every word contributes to the meaning, making it appropriately 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?

The tool is simple with one parameter and no output schema. The description explains the core function and its relationship to search_document_memory, which is essential context. However, it doesn't detail return value structure, error behavior, or prerequisites like 'call search_document_memory first', leaving some gaps for an AI agent.

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 provides one integer parameter, section_id, with no description (0% coverage). The description compensates by indicating that the section comes from search_document_memory, implying that section_id is the ID from that search result. This adds meaning but is indirect; it doesn't explicitly state that section_id must be an ID obtained from that tool.

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 ('Fetch') and resource ('one exact detailed memory section'), and it distinguishes from the sibling 'search_document_memory' by noting the section is 'returned by' that tool. However, it doesn't explicitly contrast with other siblings like 'fetch' or 'get_document_memory', so it's specific but not fully differentiated.

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 after running search_document_memory, since it says the section is 'returned by' that tool. But it doesn't explicitly state when to use this tool versus alternatives, nor provide exclusions or alternative tool names. The guidance is implicit rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_document_memoryB
Read-only

Get a compact overview. Sections are excluded by default and always strictly capped.

ParametersJSON Schema
NameRequiredDescriptionDefault
record_idYes
section_limitNo
include_sectionsNo

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context that sections are excluded by default and always strictly capped, which goes beyond annotations. However, it does not disclose what exactly the overview contains, pagination, or the nature of the cap beyond the section_limit parameter.

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 concise, with two short sentences that are front-loaded ('Get a compact overview') and no verbosity. Every sentence adds value, though the content is sparse. It is compact, fitting the tool's 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?

For a simple read-only tool with 3 parameters and no output schema, the description provides a baseline: it conveys the tool's compact nature and section behavior. However, it leaves ambiguities about what 'overview' includes (e.g., metadata, summaries) and lacks clarity on return format or when to use this vs. fetching a full document. The description does not fully compensate for the absent output schema.

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 carries the burden for parameter meaning. It only indirectly references sections via 'Sections are excluded by default' (relating to include_sections) and 'always strictly capped' (relating to section_limit), but does not explicitly explain record_id, section_limit, or include_sections. This is insufficient for full parameter comprehension.

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 'Get a compact overview' clearly indicates the tool retrieves a condensed view of a document memory, which is distinct from sibling tools like fetch_document_section or search. However, it lacks specifics on the exact resource scope or what 'overview' includes beyond sections, so it is slightly vague.

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 usage guidance is provided. The description does not state when to use this tool vs alternatives like fetch_document_section or search, nor does it mention prerequisites or exclusions. The context of siblings implies it is for a high-level summary, but this is not articulated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_sourcesA
Read-only

List enabled sources and whether each is ready.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context about 'enabled' and 'ready' states, going beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the action and resource. Every word earns its place, with no redundancy or irrelevant detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter listing tool with an output schema, the description is complete. It states the essential purpose and outcome, and since an output schema exists, explaining return values is unnecessary.

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?

There are zero parameters, so the description has no parameter details to add. Per the rubric, a baseline of 4 is appropriate, and the description correctly remains silent on parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and clearly identifies the resource ('enabled sources') plus the outcome ('whether each is ready'). It distinguishes itself from sibling tools focused on searching or fetching by describing a list operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool: to list enabled sources and their readiness. It does not explicitly state when not to use it or name alternatives, but given the sibling tools are all about searching/fetching, the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_document_memoryB
Read-only

Search detailed page-cited memories. Returns at most 10 bounded section summaries.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
record_idNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the concrete behavioral trait that the result is capped at 10 bounded section summaries, but it does not explain authentication, rate limits, or the meaning of 'page-cited' beyond surface-level wording.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the tool's purpose and output characteristics, earning the highest score for conciseness.

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?

Despite having an output schema and annotations, the description is incomplete for a tool with three parameters and multiple sibling tools. It does not explain how record_id scopes the search, when to use this over 'search' or 'search_insights', or what qualifies as a 'section summary'. The presence of an output schema does not offset the lack of parameter and usage context.

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, but it does not. It only implies the 'query' parameter and vaguely references the output limit; it entirely omits the role of 'record_id' and the precise semantics of 'limit'. This leaves three parameters under-explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Search') and a specific resource ('detailed page-cited memories'), and further narrows the output to 'bounded section summaries.' This distinguishes it from generic sibling tools like 'search' and 'search_insights' by focusing on document memory and page citations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives such as 'search', 'search_insights', or 'get_document_memory.' The description only states what the tool does, not the conditions or situations where it should be preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_insightsA
Read-only

Search locally generated keep-only summaries. Use record_id with fetch to inspect evidence.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds extra context by specifying the data domain ('locally generated keep-only summaries') and the result follow-up workflow. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short, purposeful sentences. It front-loads the core purpose and then gives an actionable secondary instruction. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (two params, no nested objects) and the presence of an output schema, the description covers the essential purpose and workflow. It lacks explicit parameter semantics and differentiation from siblings, but overall provides sufficient context for a basic search 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 description must explain the parameters. It only mentions 'query' implicitly through the verb 'Search', and 'record_id' is mentioned but is not a parameter. The 'limit' parameter is not described at all, leaving a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Search' and the resource 'locally generated keep-only summaries', which distinguishes it from sibling search tools. It also provides a follow-up action with fetch, further clarifying its role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for searching local keep-only summaries and suggests using fetch with record_id, but it does not explicitly state when to choose this over sibling search tools like 'search' or 'search_document_memory'. No exclusionary guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updatesv0.1.0
    • First observedfetch
    • First observedfetch_document_section
    • First observedget_document_memory
    • First observedlist_sources
    • First observedsearch
    • First observedsearch_document_memory
    • First observedsearch_insights
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation4/5

The tools target distinct resources (sources, insights, document memory, sections) with clear action verbs. Search and search_document_memory could be confused, but descriptions specify different targets, making the separation mostly clear.

Naming Consistency4/5

All tool names use snake_case and follow a mostly predictable verb_noun pattern (list_sources, search_insights). A few names like 'search' and 'fetch' lack an explicit object, which creates minor inconsistency, but the style is uniform.

Tool Count5/5

With 7 tools, the count is well within the ideal range and each tool seems purposefully designed to cover a distinct operation in the search/retrieval workflow, earning its place.

Completeness4/5

The set covers listing sources, searching multiple data types, and fetching specific items or sections, which is complete for a read-only retrieval system. A minor gap is the lack of a way to browse all memory sections without searching, but it's not a major dead end.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Chronicle Beta

    AnirudhB-6001
    A
    license
    A
    quality
    D
    maintenance
    A local-first personal RAG memory system that turns AI conversation history into a searchable, retrievable knowledge base via MCP, enabling LLMs to semantically search past conversations.
    2
    9
    AGPL 3.0

  • Engram

    Kalyan-Deva
    A
    license
    Not graded
    quality
    B
    maintenance
    A local-first memory MCP server that enables storing, searching, and managing personal memories with hybrid keyword and semantic recall, all on-device.
    21
    MIT

  • Memex

    arnavbee
    A
    license
    A
    quality
    B
    maintenance
    A local-first, privacy-first MCP server that passively indexes personal digital activity (screenshots, clipboard, notes, downloads, links) into a local database, enabling LLMs like Claude to access your context without cloud storage.
    4
    MIT

Latest Blog Posts

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/The-Sequence/chronicle'

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