Enables tracking professional achievements via natural language conversation in VS Code Copilot, using tools to log evidence, attach screenshots, and generate reports.
Stores evidence notes, reports, and summaries as structured Markdown files in an Obsidian vault, organized by year and appraisal level.
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., "@Appraisal Tracker MCP Log that I got my Azure AI Fundamentals certification today"
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 local MCP (Model Context Protocol) server that connects to VS Code Copilot and helps you track your annual performance appraisal by logging evidence directly into an Obsidian vault — using natural language conversation.
Instead of manually filling spreadsheets or forgetting what you accomplished, you just tell Copilot what you did and it handles the rest: asks follow-up questions, maps the achievement to your appraisal goals, attaches screenshots, and writes structured Markdown notes to your vault.
Log professional achievements conversationally — no forms, no structure needed
Automatically maps evidence to appraisal goals by rubric
Attaches screenshots or images to evidence notes
Lists all logged evidences with filters
Generates a full appraisal evidence report
Generates a mid-year summary note (English, Spanish, or both)
Generates an actionable game plan for completing remaining goals
Related MCP server: bragdoc-mcp
Tool | What it does |
| Save an achievement and link it to appraisal goals |
| Look up all goals for a level |
| List logged evidences with optional filters |
| Generate a full Markdown report organized by rubric and goal |
| Generate a mid-year summary note (English, Spanish, or both) |
| Generate a prioritized game plan for remaining goals |
| Attach or add an image to an existing evidence note |
Node.js v18+ — recommended to use nvm
VS Code with the GitHub Copilot extension
Obsidian (optional but recommended — the vault is just a folder of Markdown files)
git clone https://github.com/your-username/appraisal-tracker-mcp.git
cd appraisal-tracker-mcpnode --version # make sure you're on v18+
npm installCopy the example env file and edit it:
cp .env.example .envOpen .env and set your paths:
OBSIDIAN_VAULT_PATH=/Users/yourname/Documents/YourVault
TRACKER_FOLDER=Appraisal Tracker
DEFAULT_LEVEL=lead_consultantOBSIDIAN_VAULT_PATH — the root folder of your Obsidian vault (or any folder where you want the notes saved)
TRACKER_FOLDER — the subfolder inside the vault where all tracker files will be created
DEFAULT_LEVEL — your appraisal level. The server uses this automatically so you never have to specify it in conversation. Change it to match your level (e.g., senior_consultant, principal_consultant)
node --version # confirm Node 18+
npm run build # compiles TypeScript to dist/If you're using nvm and the wrong Node version is active, run:
nvm use 20
npm run buildCreate a .vscode/mcp.json file in this project (or in any workspace you want to use the tracker from):
{
"servers": {
"appraisal-tracker": {
"type": "stdio",
"command": "/absolute/path/to/node",
"args": ["/absolute/path/to/appraisal-tracker-mcp/dist/index.js"],
"env": {
"OBSIDIAN_VAULT_PATH": "/Users/yourname/Documents/YourVault",
"TRACKER_FOLDER": "Appraisal Tracker",
"DEFAULT_LEVEL": "lead_consultant"
}
}
}
}Important: Use the absolute path to your Node binary — ${workspaceFolder} does not work here.
To find your Node path:
which node
# or if using nvm:
nvm which 20Open the Command Palette (Cmd+Shift+P / Ctrl+Shift+P)
Search for "MCP: List Servers"
Find appraisal-tracker and click Start Server
Open Copilot Chat, switch to Agent mode
You should see the tools listed — you're ready to go
YourVault/
└── Appraisal Tracker/
├── attachments/ ← screenshots and images go here
├── evidences/
│ └── 2026/
│ └── lead_consultant/
│ ├── ev_20260427_001.md
│ └── ev_20260518_001.md
├── reports/ ← generated by generate_report
├── 2026 Mid-Year Summary.md
├── 2026 Resumen Mid-Year.md
└── 2026 Game Plan.mdOpen Copilot in Agent mode and just talk to it naturally:
Logging an achievement:
"I got my Azure AI Fundamentals certification today"
Copilot will ask follow-up questions (date, people involved, outcome, do you have a screenshot?) and then save the evidence note automatically.
Attaching a screenshot:
Save your screenshot to
YourVault/Appraisal Tracker/attachments/first, then tell Copilot: "Add the latest screenshot to that evidence"
Generating a summary:
"Generate my mid-year summary in both English and Spanish"
Generating a game plan:
"Generate my game plan. I'm currently working on: a dashboard for banking users, a skill meter tool, and studying for the AI-102 certification"
Listing what you've logged:
"Show me all my evidences for this year"
Currently includes goals for lead_consultant. To add another level (e.g., Senior Consultant, Principal, etc.):
Add a new file at src/data/appraisals/senior_consultant.json (use lowercase and underscores for the filename).
The file must follow this structure:
{
"level": "senior_consultant",
"displayName": "Senior Consultant",
"rubrics": [
{
"id": "develop_business",
"name": "Develop your business",
"goals": [
{
"id": 1,
"description": "Description of goal 1 exactly as it appears in the appraisal rubric"
},
{
"id": 2,
"description": "Description of goal 2"
}
]
},
{
"id": "develop_yourself",
"name": "Develop yourself",
"goals": [
{
"id": 7,
"description": "Obtain a technical certification aligned to your technology stack"
}
]
},
{
"id": "manage_business",
"name": "Manage your business",
"goals": []
},
{
"id": "support_customers",
"name": "Support your customers",
"goals": []
}
]
}Rules:
level must match the filename exactly (e.g., senior_consultant → senior_consultant.json)
id inside each rubric must be one of: develop_business, develop_yourself, manage_business, support_customers
Goal id can be a number (1, 2) or a string for sub-goals ("6a", "6b")
Copy the goal descriptions directly from the official appraisal document so they match exactly
.env and mcp.jsonUpdate DEFAULT_LEVEL in your .env file:
DEFAULT_LEVEL=senior_consultantAnd in .vscode/mcp.json under env:
"DEFAULT_LEVEL": "senior_consultant"This is the level the server will use automatically — you never have to specify it in conversation.
npm run buildOpen MCP: List Servers from the Command Palette and restart appraisal-tracker.
Now you can tell Copilot:
"Add evidence for level senior_consultant — I led a client demo today"
Or generate a summary for that level:
"Generate my mid-year summary for senior_consultant"
You can have multiple levels active at the same time — each one stores its evidences in its own subfolder inside the vault (evidences/2026/senior_consultant/).
Goals are organized in 4 rubrics:
Rubric | Description |
| Business development, mentoring, case studies, sales support |
| Certifications, learning, communication, technical growth |
| Compliance, utilization, processes, professional development |
| Delivery quality, client relationships, team support |
The file .github/copilot-instructions.md controls how Copilot behaves as an agent — what questions it asks before saving evidence, the tone it uses, and how it maps goals.
Edit this file to adjust the behavior for your workflow.
TypeScript + Node.js
@modelcontextprotocol/sdk — MCP server implementation
zod — input validation
dotenv — environment configuration
Plain Markdown files as storage (no database)
Add a new evidence or achievement and link it to the appraisal goals it fulfills
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date of the evidence in YYYY-MM-DD format, defaults to today | |
| goals | Yes | List of goal numbers this evidence addresses | |
| level | No | Appraisal level (e.g., lead_consultant). Defaults to the configured DEFAULT_LEVEL. | |
| title | Yes | Short title for the evidence | |
| rubric | Yes | Rubric ID this evidence belongs to: develop_business | develop_yourself | manage_business | support_customers | |
| context | Yes | Explanation of why this evidence meets the goal(s) | |
| description | Yes | Detailed description of what was done or achieved | |
| use_latest_image | No | If true, picks the most recent image from the Inbox folder and attaches it to the evidence |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions adding and linking, but fails to disclose side effects, required permissions, rate limits, or whether the operation is reversible. The minimal description 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (15 words) that front-loads the core action. While it could benefit from additional detail, it contains no wasted words and is appropriately sized for a straightforward creation tool.
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 complexity (8 parameters, 5 required) and the absence of an output schema and annotations, the description is insufficient. It does not explain what happens after creation, how goals are linked, or what the response entails, leaving significant contextual gaps.
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 for all 8 parameters, so the baseline is 3. The tool description adds a high-level purpose ('link to appraisal goals') but does not elaborate on parameter meanings or relationships beyond what the schema already provides.
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 'Add', the resource 'new evidence or achievement', and the context 'link it to the appraisal goals it fulfills'. It effectively distinguishes from sibling tools like list_evidences (listing) and update_evidence_image (updating images).
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 for creating new evidence, but provides no explicit guidance on when to use this tool vs. alternatives (e.g., update functions), nor does it mention any prerequisites or exclusions. The usage context is clear but lacks directive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an actionable game plan for completing remaining appraisal goals, with an accomplishments list for the supervisor and optional current initiatives section
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year to generate the plan for, defaults to current year | |
| level | No | Appraisal level (e.g., lead_consultant). Defaults to the configured DEFAULT_LEVEL. | |
| current_initiatives | No | List of current projects or initiatives to include in the 'what I'm working on' section |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, has side effects, or requires authentication. The description only hints at output structure without 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?
Single sentence, front-loaded with the primary action and key output components. No wasted words.
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?
The description names the output sections but lacks details on return format or structure (no output schema). For a tool with three optional parameters, it is adequate but not fully complete.
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 coverage is 100%, so the baseline is 3. The description adds minimal context beyond the schema, clarifying that current_initiatives is optional and part of the output. No further parameter details are provided.
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 it generates a game plan for appraisal goals, mentioning specific components (accomplishments list, current initiatives). However, it does not explicitly differentiate from sibling tools like generate_report or generate_summary, which have similar names.
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 for completing remaining appraisal goals, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a full markdown report of evidences organized by rubric and goal, saved to Obsidian
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year to generate report for, defaults to current year | |
| level | No | Appraisal level to generate the report for. Defaults to the configured DEFAULT_LEVEL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: 'saved to Obsidian' (side effect). However, it lacks details on permissions, rate limits, error conditions, or whether the tool is purely read-only (it modifies storage). Adequate but not fully transparent.
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, front-loaded sentence that includes all key elements (generate, report, organization, format, destination). No extraneous words.
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 no output schema, the description explains the output format and destination. It covers the content (evidences by rubric and goal). For a tool with two optional parameters and straightforward behavior, this is fairly complete. Could mention if the report is returned or only saved, but overall good.
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 coverage is 100% and both parameters have descriptions. The tool description adds context about defaults (year defaults to current, level defaults to DEFAULT_LEVEL) and the nature of the report ('full markdown report'). This provides some added value beyond the schema, but does not significantly expand on parameter behavior. 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 'generate', the resource 'report of evidences', the organization 'by rubric and goal', and the output format/destination 'markdown report saved to Obsidian'. It effectively distinguishes from siblings like generate_summary and generate_game_plan.
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 explicit guidance on when to use this tool versus alternatives, no context on prerequisites, and no advice on when not to use it. It only states what the tool does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a mid-year appraisal summary note in English, Spanish, or both, saved to the Obsidian vault
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year to summarize, defaults to current year | |
| level | No | Appraisal level (e.g., lead_consultant). Defaults to the configured DEFAULT_LEVEL. | |
| language | No | Language for the summary: en (English), es (Spanish), or both. Defaults to en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses saving to the Obsidian vault and language options, but does not explain whether the note overwrites or appends, or any permission requirements. This is adequate but not detailed.
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?
A single, well-structured sentence that conveys the core purpose and key variations (languages, destination) with zero redundancy.
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?
The description covers the main action and destination, but does not explain the output (e.g., success message, file path) or behavior if a note already exists. With no output schema, this information would be helpful.
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 the schema already documents all three parameters (year, level, language). The description does not add extra meaning beyond what the schema provides, meeting the baseline.
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 tool generates a mid-year appraisal summary note, specifies languages (English, Spanish, or both), and indicates it is saved to the Obsidian vault. This specific verb-resource combination distinguishes it from siblings like generate_report and generate_game_plan.
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 is provided on when to use this tool versus alternatives such as generate_report or add_evidence. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all appraisal goals for a specific level
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Appraisal level (e.g., lead_consultant, senior_consultant). Defaults to the configured DEFAULT_LEVEL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It indicates a read operation but omits details like the output format, default level behavior, or any authentication requirements. The description adds some transparency but lacks completeness for a tool with no annotated hints.
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, focused sentence of nine words. It efficiently communicates the core action without any redundant information, achieving excellent conciseness.
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?
The tool has no output schema, so the description should explain the return format or list structure. It does not mention what constitutes an 'appraisal goal' or whether the result is a list. The description is too minimal to fully inform an agent about the tool's complete behavior.
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 already describes the 'level' parameter with 100% coverage. The description adds no additional meaning beyond restating the parameter's purpose. Given high schema coverage, a 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 the resource 'appraisal goals', specifying the scope 'for a specific level'. This directly conveys the tool's function and distinguishes it from siblings like generate_report or list_evidences, which involve different 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 does not mention prerequisites, typical scenarios, or cases where a different tool would be more appropriate, leaving the agent without contextual selection advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all stored evidences with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Filter by year in YYYY format, defaults to current year | |
| level | No | Filter by appraisal level | |
| rubric | No | Filter by rubric ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not mention that the tool is read-only, nor does it disclose any behavioral traits like pagination, rate limits, or safety. The name implies listing, but the description adds no explicit 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?
Single sentence, no wasted words. Efficient but could benefit from slightly more detail without harming conciseness.
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?
The description is too minimal. It does not explain what evidences are, the return format, pagination, or ordering. Given the sibling tools, more context is needed to guide selection and usage.
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 coverage is 100% with descriptions for all three parameters (year, level, rubric). The description adds no additional meaning beyond the schema, achieving the baseline of 3 for high coverage.
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 'List all stored evidences with optional filters', specifying the verb and resource. It distinguishes from sibling tools like add_evidence (create) and generate_report (report) by implication, but does not explicitly differentiate.
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. The description only mentions 'optional filters' without explaining scenarios where filtering is appropriate or when to use other tools like generate_report or get_appraisal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach or replace the image of an existing evidence using the latest image in the Inbox folder
| Name | Required | Description | Default |
|---|---|---|---|
| evidence_id | Yes | The ID of the evidence to update (e.g., ev_20260728_001) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action but fails to disclose side effects (e.g., replaces existing image), whether changes are reversible, or required permissions. For a tool that modifies evidence, this is insufficient.
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?
Single sentence clearly and efficiently conveys the tool's purpose with no unnecessary words. Front-loaded action.
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?
Adequate for a simple tool with one parameter, but lacks details on success/failure outcomes, return value, and behavioral context. Given no output schema or annotations, description could provide more completeness.
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 coverage is 100% and already describes evidence_id format. Tool description does not add extra meaning beyond schema, so baseline 3 applies.
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?
Clearly states verb (attach/replace), resource (image of evidence), and source (latest image in Inbox). Distinguishes from siblings like add_evidence and list_evidences.
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?
Implies usage context via 'latest image in Inbox folder' but lacks explicit when-to-use, prerequisites, or alternatives. No guidance on when to use vs other tools.
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.
v1.0.0add_evidencegenerate_game_plangenerate_reportgenerate_summaryget_appraisallist_evidencesupdate_evidence_imageScored across 7 tools
Each tool has a clearly distinct purpose: generating different outputs (report, summary, game plan), managing evidences (add, list, update image), and retrieving appraisal goals. No two tools overlap in functionality.
All tool names follow the verb_noun pattern consistently (e.g., generate_report, add_evidence, get_appraisal). The verbs are diverse but descriptive, and there is no mixing of naming conventions.
With 7 tools, the server covers core workflows for an appraisal tracker without being bloated or insufficient. The number fits the domain well.
The tools cover adding and listing evidences, updating evidence images, and generating various reports. However, missing update/delete for evidences and any CRUD for appraisal goals (only get) leaves noticeable gaps for a complete lifecycle.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Privacy-first work tracking with summaries, reports, coaching, and AI-ready long-term memory.
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
