devrecall
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| current_timeA | Return the current time, in the user's local timezone and in UTC. Prefer |
| list_activitiesA | List activities in a time window with optional source/type/person filters. Returns shallow rows (no body); use get_activity to fetch full content. |
| count_activitiesA | Count activities in a time window, optionally grouped by source, type, identity, day, or week. The primitive behind 'how many', 'how often', and 'compare X vs Y' questions. |
| search_activitiesA | Hybrid search over activity titles and content, combining keyword (FTS5) and semantic similarity. This is the default search tool — it handles both concrete phrases like 'retry strategy' and loosely-worded queries, so prefer it unless you specifically need pure vector similarity. |
| semantic_search_activitiesA | Pure vector similarity search over activities. search_activities already blends this with keyword matching, so reach for this only when that returns nothing useful and the query is purely conceptual with no reliable keywords. Returns shallow rows ranked by similarity. |
| get_activityA | Fetch the full activity row (including content and metadata) for a given activity ID. Use after list_/search_ to drill into a specific row. |
| get_related_activitiesA | Find activities that share a ticket key with the given activity — e.g. given a Jira ticket, returns the commits / PRs / Linear issues / Confluence pages that reference the same key. Use this to assemble the full timeline around one piece of work. |
| get_work_itemA | Fetch a work item (a ticket or PR and everything linked to it) with its full cross-source timeline: the ticket, its commits, PRs, reviews, and discussions in chronological order. The best tool for 'show me everything about PROJ-123'. |
| list_work_itemsA | List work items (tickets/PRs with their linked activity), most recently active first. The structural answer to 'what was I working on last week' — each item groups a ticket with its commits, PRs, and discussions. Use get_work_item for the full timeline of one item. |
| who_worked_onA | Activities authored by a specific person, optionally narrowed by a keyword query and date range. Pass identity_id if you have one (from list_identities/resolve_person); otherwise pass name_or_email and the tool resolves it. |
| recent_decisionsA | Find decision-shaped activity in a date range: manual notes (type=note) merged with anything whose title or body hits decided/decision/RFC/ADR. Use this before answering 'what did we decide about X' or composing a quarterly summary. |
| prep_meetingA | Brief for a calendar meeting: returns the event details plus each attendee's recent shipped activity. Look up by activity_id if known, otherwise by date+title_contains. Use this to walk into a 1:1 or sync knowing what everyone's been doing. |
| log_eventA | Record a manual note — a decision, in-person conversation, observation, or anything else worth remembering. Stored as type=note from source=manual and indexed alongside everything else. Use this when the user dictates context you want recallable later. |
| list_summariesA | List pre-built periodic summaries (daily/weekly/monthly/quarterly). Prefer these over re-summarizing raw activities when answering 'summarize my Q1' or 'what happened last week'. |
| get_summaryA | Fetch a single pre-built summary by period type and start date. Returns null if no summary exists for that period. |
| list_identitiesA | List people known to the system (Git authors, Slack users, etc.), optionally filtered by a name/email substring. |
| resolve_personA | Resolve a name or email to a single identity (the closest match). Returns the matched identity or null if no candidate is found. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| devrecall-recall | Search DevRecall for activity matching a query and report the most relevant hits with citations. |
| devrecall-context | Inject a brief of recent activity so the assistant starts knowing what's been going on. |
| devrecall-log | Capture a note into DevRecall without leaving the editor. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Most tools have clearly distinct purposes—search, list, count, drill-down, and work-item aggregation are separated well. The main overlaps are get_related_activities vs get_work_item, and search_activities vs semantic_search_activities, but the descriptions provide enough guidance to choose correctly.
The core set follows a consistent verb_noun snake_case pattern like list_activities, count_activities, and resolve_person. A few names deviate—who_worked_on, recent_decisions, current_time, and the abbreviated prep_meeting—but the overall style remains readable and predictable.
At 17 tools, this is slightly above the ideal 3-15 range, but the server covers a broad domain spanning activity search, work items, people, summaries, and meeting prep. Most tools earn their place and support distinct workflows rather than padding the surface.
The read/query surface is strong: search, list, count, drill-down, person resolution, work-item aggregation, and pre-built summaries cover the main recall workflows. The notable gap is that log_event supports creating manual notes but there is no update or delete path, and there is no explicit metadata tool for enumerating sources or types.