Bridge Claude Code conversations into Obsidian. Search, explore, and archive your AI coding history.
ccfolio exposes 5 search and analytics tools for Claude Code conversation history. All tools have descriptions and input schemas with typed parameters. However, there are significant gaps in schema documentation, parameter descriptions lack detail, and output schemas are not formally documented. Tools follow a consistent naming pattern (verb_noun) and are read-only, which is appropriate. The main weakness is that descriptions are text-only and outputs are returned as formatted strings rather than structured JSON, forcing LLMs to parse unstructured text.
Find all sessions that read, wrote, or edited a file. Use this to find past conversations that touched a specific file. Partial paths work (e.g., "CLAUDE.md" matches any path containing it).
Get cost breakdown for Claude Code usage.
Get detailed information about a specific session.
List recent Claude Code sessions.
Search across all Claude Code conversations (full-text + substring). Searches user messages, assistant responses, summaries, titles, slugs, and file paths. Supports both whole-word and partial/substring matching. For example, searching "folio" will find sessions containing "ccfolio".
All tools return formatted string text rather than structured JSON. LLMs must parse unstructured output (string concatenation with newlines and formatting), which is error-prone and wastes tokens. Baseline: return_type should be documented and structured.
Parameter descriptions are inconsistent and lack detail. 'count' in list_recent_sessions has a description, but 'limit' in search_sessions is terse. 'period' in get_cost_summary only lists allowed values inline without constraint details. Parameter descriptions should include ranges, format requirements, and valid enum values explicitly.
Output schema is not documented. The code shows tools return strings with formatted text, but users need to know: What fields are in the response? What are the column names? What are the data types? This is required for LLM composition (pattern:tool-chain).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
No pagination support documented. search_sessions accepts 'limit' but no offset, page_number, or cursor. For a tool querying conversation history, large result sets could blow context windows. No guidance on how to fetch more results beyond the limit.
Error handling is minimal. Tools return plain text strings like 'No sessions found...' or 'Session not found...'. No classification of errors (retryable, user-fixable, fatal). No guidance on recovery, e.g., if a session_id is not found, should the user search first? Currently returns bare 404-like strings.
get_session_details accepts 'session_id' but description is sparse: 'Full session UUID, UUID prefix, or slug'. Does not explain which format to try first, or what a slug looks like. LLMs may be confused about whether to pass a full UUID, a partial match, or a human-readable slug.
list_recent_sessions 'sort_by' parameter lists allowed values inline (date, cost, messages, tokens) without an explicit enum constraint. Should use JSON Schema enum to make valid options machine-parseable.
get_cost_summary 'period' parameter description only lists values; missing guidance on when to use each. 'daily' vs 'monthly' vs 'model' vs 'project', when is each appropriate? What is the default behavior if both 'period' and 'after' are provided?