What can you do with this server?

The agent-kit server is a read-only MCP server that provides access to a personal knowledge base, platform skills, agents, shared references, context guides, and private personal memory. You can: * Browse and retrieve skills, agents, references, and context guides with content chunking (full, sections, or TOC) for efficient token use. * Manage local, private memory: list entries, fetch by name, and full-text search. * Perform full-text search across all platform knowledge (skills, agents, references, guides, CLAUDE.md) and personal memory. * Get diagnostic token usage statistics (summary or detailed). All operations are read-only and served over stdio.

Which integrations are available for this server?

Projects the knowledge base content into an Obsidian vault (symlinks on POSIX, copies on Windows) for browsing and use within the Obsidian note-taking app.

How do I use agent-kit?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agent-kit list skills related to deployment" 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.

agent-kit

by chris-dare-dev

Overview Schema Related Servers Score Discussions

Python

Local

agent-kit

A provider-neutral agent kit and a local artifact-memory substrate for a personal multi-repo workspace.

Two things live here:

A knowledge kit — skills, agents, entrypoints and references maintained once, compiled into per-provider packs (Claude Code, Codex CLI, OpenCode) by generators, and served to a Claude Code session over MCP.
An artifact-memory substrate — a local pipeline that catalogs the workspace's canonical Markdown, chunks it into an immutable outbox, embeds it locally, and serves semantic search from a loopback Qdrant behind a resident Unix-socket service. Nothing leaves the machine.

Design rules

Canonical Markdown is the source of truth. The search index is derived — a discovery hint, never an authority. Retrieve the real file before acting.
Derived state is rebuildable; canonical state is never rewritten to fix an index.
Fail closed. A hash mismatch, a missing build manifest, an incomplete backup: each stops the pipeline and says so rather than shipping something unverified.
Local embeddings only. A pinned ONNX model (all-MiniLM-L6-v2, 384-dim) loaded from a digest-checked local snapshot; runtime downloads are refused.

Related MCP server: mcp-service

⚠️ The rebuild rule — read before editing `src/`

The registered server command runs the compiled output (node dist/index.js), not the TypeScript source. An edit under src/ is invisible until you npm run build and restart the Claude Code session (the MCP server is spawned per session). npm run dev runs the source directly, but that is not what Claude Code launches.

Content under data/ is loaded once at server startup — no hot reload, but no rebuild needed either. Restart the session after editing it.

Architecture

canonical Markdown
      ├─────────────► artifact_catalog.py ──► catalog (sqlite, exact sha256)
      │                                            │
skills │ emit receipts                             ▼
      │                        artifact_ingestion.py ──► immutable gzip-JSONL outbox
      ▼                                            │
 skill-events/  ──► artifact_event_consumer.py ────┤ (checkpointed, dead-lettered)
                                                   ▼
                                    Qdrant (loopback, API-keyed)
                                                   │
                                artifact_memory_service.py (resident, UDS)
                                                   │
                                       MCP tools ──┘  search_artifacts / get_artifact

Support plane: an external watchdog (a dead consumer cannot announce its own death), a composite health watermark, an age-encrypted off-device backup with a fail-closed --verify, a reversible quarantine, and a retention classifier that defaults to RETAIN.

MCP tools (17)

Group	Tools
Skills / agents	`list_skills`, `get_skill`, `list_agents`, `get_agent`
References	`list_references`, `get_reference`
Context guides	`list_context_guides`, `get_context_guide`
Memory (local, private)	`list_memory`, `get_memory`, `search_memory`
Search	`search_platform_knowledge`
Artifact memory	`artifact_memory_status`, `search_artifacts`, `get_artifact`, `query_temporal_facts`
Diagnostics	`get_token_stats`

All are read-only. The server exposes exactly one transport (stdio); a static tripwire test fails if an HTTP/SSE transport is ever imported.

What the default profile writes to disk. Under the default SERVER_PROFILE=personal, the token log keeps a 120-character raw preview of every tool call's arguments (summarizeArgs), and the response-cache snapshot keeps raw argsKeys. Both default to $WORKSPACE_ROOT/.claude/mcp-token-log.jsonl and $WORKSPACE_ROOT/.claude/mcp-cache-snapshot.jsonl. SERVER_PROFILE=shared switches the log to hashArgs and writes to distinct *.shared.jsonl files. Both patterns are gitignored, but if you point TOKEN_LOG_PATH or CACHE_SNAPSHOT_PATH somewhere else, that is on you. Set either to "" to disable it.

Under SERVER_PROFILE=shared the personal-memory tier is excluded from both the search index and the memory tools, and the artifact-memory tools are not registered at all.

Quick start

git clone https://github.com/chris-dare-dev/agent-kit
cd agent-kit
npm ci && npm run build

claude mcp add agent-kit -- node "$PWD/dist/index.js"

No environment variables are required: with none set, the server serves the content bundled in data/ and resolves everything else relative to the package root. PLATFORM_ROOT (extra content root), WORKSPACE_ROOT, MEMORY_ROOT, CONTEXT_GUIDES_DIR and CLAUDE_MD_GLOBS are optional overrides — see the header of src/config.ts.

That block is executed by node scripts/verify-quickstart.mjs, so if it drifts from what actually works, the check fails.

Optionally, plant the bundled skills, agents, commands and hooks into a workspace's .claude/, and check your machine:

node scripts/cli.mjs init      # symlink on POSIX, copy on Windows
node scripts/cli.mjs doctor    # one PASS/FAIL/SKIP row per prerequisite

init refuses to touch anything it did not create unless you pass --force, never writes outside the clone without --install-to, and records every path it touched in .agent-kit/install-receipt.json. Run init --dry-run to see the plan first.

The substrate is separate and optional — see workspace-tooling/README.md for provisioning (Docker + Qdrant + a Python 3.12 venv from the pinned lockfile).

Supported platforms

This table is what is measured today, not what is intended. Every entry was run on Windows 11 and on Linux; macOS entries are marked as inferred where no host was available to check them.

native — runs here, no workaround. WSL2 — Windows users run it inside a WSL2 guest. partial — runs and reports, with known residue that is tracked. unsupported — declines by name; see the linked milestone.

Component	macOS	Linux	Windows
MCP server (`dist/index.js`)	native (17 tools)	native (17 tools)	native (13 tools)
Artifact-memory tool group (4 tools, Unix socket)	native	native	unsupported — no AF_UNIX (M5); WSL2 meanwhile
Generators + the seven gates	native	native	native
TypeScript suite (`npm test`)	native	native	native
Python substrate — imports and collects	native	native	native
Python substrate — passes	partial	partial	partial (#70)
Resident memory service (`artifact_memory_service.py`)	native	native	unsupported (M5); WSL2 meanwhile
Shell hooks (`data/hooks/*.sh`, bash + jq)	native	native	unsupported — fail open (M3)
Obsidian vault projection (symlinks, `dir_fd`)	native	native	unsupported (M5)
Service supervision (launchd `.plist` only)	native	unsupported (M5)	unsupported (M5)

Substrate suite, measured. The suite used to be un-importable off POSIX; M2 routed fcntl, os.geteuid and the resource/AF_UNIX dependencies through workspace-tooling/platform_compat.py, so it now collects everywhere. It does not yet pass everywhere:

	collected	failures	errors
Linux (no venv)	627	1	30
Windows 11	625	31	337

workspace-tooling/run-substrate-tests.py records these as baselines and tells you whether a run is at, above or below them — so "did I break something" is answerable without a clean tree to diff against. On POSIX, ~30 of the errors are cases that import qdrant_client at call time and clear once the provisioned venv is used. The Windows residue (SQLite handles held across tempdir teardown, macOS-only launchd fixtures) is #70.

macOS is inferred, not measured. No macOS host was available. Its rows assume POSIX parity with Linux, which is what the code implies but not something anyone has run.

Unsupported means it says so. artifact_memory_service.py on Windows exits 2 in under a second naming the platform, the missing AF_UNIX support, and the WSL2 alternative — rather than emitting a cascade of import errors that read like substrate defects.

On Windows the MCP server starts and serves the 13 non-substrate tools, and says on stderr exactly which group is unavailable and why.

Testing

npm run test:all        # everything below that runs without a provisioned substrate

npm run test:unit       # all 10 TypeScript suites (globbed) + init + uninstall
npm run gates           # every generator gate, consistency check and shell harness
npm run verify:quickstart

# substrate suite — runs on every OS and reports against a recorded baseline
# (Linux 627 collected / 1 fail / 30 error; Windows 625 / 31 / 337). Exits
# non-zero whenever anything failed, matching baseline or not.
npm run test:substrate

# The substrate suite needs the provisioned venv to clear ~30 of those errors:
# they are cases that import qdrant_client at call time. It is NOT part of
# test:all for that reason. Windows residue is tracked as #70.

# `npm run gates` above runs all of these and prints one named line per gate;
# reach for them individually only when you want one gate's own diagnostics.
# No PYTHONUTF8 needed: every text I/O in data/scripts names its encoding, and
# catalog provenance is POSIX-separated, so these are byte-identical on Windows,
# macOS and Linux. Both were verified on Windows AND Linux.
python3 data/scripts/catalog-generate.py --check
python3 data/scripts/generate-adapter-packs.py --check
python3 data/scripts/generate-root-contract.py --check
python3 data/scripts/model-policy-apply.py --check
python3 data/scripts/mcp-server-name-check.py --check
python3 data/scripts/denylist-check.py --check
python3 data/scripts/template-settings-check.py --check

The last one is why a rename is survivable: every mcp__<server>__ tool grant in data/**/*.md must name a server that all three shipped registration templates register. Change the server name and it tells you every file still carrying the old grant.

agent-kit doctor runs all of the above prerequisite checks in one pass, with the right encoding, and prints a fix command per failure.

AGENTS.md and CONTEXT.md are generated — edit the coverage map, then regenerate.

Layout

Path	What
`src/`	MCP server (TypeScript → `dist/`)
`data/skills`, `data/agents`, `data/commands`, `data/references`	the knowledge base
`data/scripts`	generators, validators, pipeline tooling
`data/hooks`	PreToolUse guards (incl. the plaintext-credential blocker)
`workspace-tooling/`	the artifact-memory substrate + its tests

Provenance

This kit began as a personal fork of an internal tool I built at work, then was genericized: the employer-specific integrations, infrastructure facts, and operational tooling were removed, and the remaining machinery renamed. What is left is the general architecture — the generators, the guard, the memory substrate — plus content I use on my own projects.

src/security/aidefence-rules.ts transcribes detection patterns from ruflo (MIT) as data; see that file's header for the attribution and the one deliberate deviation.

Requirements

Server: Node ≥ 20. Nothing else — macOS, Linux and Windows alike.

Substrate (optional): Python 3.12 · Docker (Qdrant). The Python modules and their test suite import and run on macOS, Linux and Windows; the resident memory service needs a Unix-domain socket, so on Windows it runs inside WSL2 — see Supported platforms and docs/platforms/windows-wsl.md.

Available Tools

13 tools

get_agentA

Get the definition for one named platform agent. Supports section chunking: omit section for full content (small agents) or auto-summary (large agents); pass section: "list" for headings, section: "<slug>" for one section, or section: "all" for full content.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Agent name (e.g., argocd-ops, gitops, cluster-health)
`section`	No	Optional section slug, or 'list'/'all'.

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description must disclose behavioral traits. It explains the auto-summary for large agents and the effects of each section option effectively.

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, well-structured sentence that first states the main purpose then explains the parameter usage. No wasted words.

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 moderate complexity of section chunking and no output schema, the description covers the core functionality well. It omits specifics like error handling or return format, but is sufficient for selection.

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?

Schema coverage is 100%, baseline is 3. The description adds significant value by explaining the behavior of the section parameter in various cases, going beyond the schema's brief description.

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 action 'Get' and resource 'definition for one named platform agent'. It also explains the section chunking variants, distinguishing it from sibling tools like list_agents.

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 gives detailed guidance on using the section parameter (omit, 'list', '<slug>', 'all') and explains the auto-summary behavior. While it doesn't explicitly state when not to use this tool vs siblings, 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.

get_context_guideA

Get a topical context guide. Topic supports partial matching (e.g., 'mesh' -> 'service-mesh'). Large guides default to a chunked summary (intro + TOC); pass section: "<slug>" for one section, section: "list" for TOC only, or section: "all" for full content. Use chunking to save tokens when you only need part of the guide.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	Topic name or partial match
`section`	No	Optional section slug, or 'list'/'all'.

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses partial matching behavior with examples, chunking for large guides, and section parameter effects. Adequate for a read-heavy retrieval tool, though auth/rate limits not mentioned.

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?

Three concise sentences. Front-loaded with purpose, then key details. No wasted words; every sentence provides useful information.

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 two-parameter tool with no output schema, description covers input behavior and chunking logic sufficiently. Lacks explicit return format details but mentions intro+TOC for large guides, which is adequate.

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

Parameters5/5

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

Schema coverage is 100%, but description adds significant value: explains partial matching with an example and clarifies section options ('<slug>', 'list', 'all') beyond the schema's brief descriptions.

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?

Description states 'Get a topical context guide' with specific verb and resource. Distinguishes from sibling tools like list_context_guides by explaining partial matching and chunking options, making the tool's unique role clear.

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 explicit guidance on when to use chunking and section parameter to save tokens. Implies alternatives by mentioning partial matching and section options, though it doesn't directly contrast with search_platform_knowledge.

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

get_memoryA

Get the full content of one personal-memory file by name (the on-disk filename stem, e.g. reference_pqc_envoyfilter_constraints). Accepts a unique substring. LOCAL/PRIVATE tier.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Memory name (filename stem) or a unique substring of it

TDQS

A4.2/5.0

Behavior3/5

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

No annotations exist, so description carries full burden. It mentions LOCAL/PRIVATE tier implying access restrictions but does not specify read-only nature, side effects, or error behavior. It adds context beyond basic action but lacks behavioral depth.

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 concise sentences front-load the core action and resource, with an example and tier hint. Every word is useful with no waste.

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 no output schema, the description lacks explanation of the return format or error cases. However, the tool is simple (1 param) and the description covers the core functionality well, so it is nearly complete.

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?

Schema coverage is 100%, baseline 3. Description adds value by clarifying the filename stem format with an example and emphasizing acceptance of unique substrings, which goes beyond the schema description.

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 'Get' and resource 'full content of one personal-memory file', with clear naming convention and example. It distinguishes from siblings like list_memory (listing) and search_memory (search).

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 usage for retrieving a specific memory by exact name or unique substring, with the example and tier hint. However, no explicit when-not or alternative tool guidance is provided.

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

get_referenceB

Get the full content of a shared reference file

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Reference name (e.g., cluster-contexts)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, and description only says 'get full content' without disclosing read-only nature, auth needs, or what 'full content' entails.

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?

Single front-loaded sentence with no waste, efficiently conveys core action.

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?

Adequate for a simple retrieval tool, but lacks details on output format and scope; similar to sister tools.

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 covers 100% parameter with example, description adds no extra meaning; baseline 3 applies.

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?

Description clearly states verb (Get), resource (shared reference file), and distinguishes from siblings like list_references.

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?

Implied usage is clear, but no explicit guidance on when to use vs alternatives like list_references or get_memory.

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

get_skillA

Get a skill's SKILL.md content. Supports section chunking: omit section for full content (small skills) or auto-summary (large skills); pass section: "list" for a TOC of headings; pass section: "<slug>" for one section; pass section: "all" to force full content.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Skill name (e.g., argocd-debug)
`section`	No	Optional section slug, or 'list'/'all'.

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses behavioral traits such as auto-summary for large skills, chunking options, and forced full content with 'all'. However, it does not address error handling (e.g., missing skill) or permissions, which are minor gaps. Overall, it provides good behavioral insight.

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 sentence that efficiently packs the purpose and all usage modes. It is front-loaded with the core action and expands with clear, well-structured options. Every word earns its place; no redundancy.

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 lack of an output schema, the description adequately explains the different return formats (full content, TOC, single section). It does not explicitly state that the response is markdown text, but 'SKILL.md content' implies that. For a simple getter tool, this is mostly complete, though a note on the response type would improve it.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant value beyond the schema. It explains the behavior of each section value ('list' for TOC, '<slug>' for one section, 'all' for full content, omit for auto-summary) and the context of small vs large skills. This enriches the parameter semantics substantially.

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 'Get' and resource 'skill's SKILL.md content', providing a specific and unambiguous purpose. It distinguishes from sibling tools like list_skills (listing vs. getting content) and get_agent (different resource). The section chunking detail adds further specificity.

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 provides detailed guidance on how to use the section parameter (omit, 'list', '<slug>', 'all') but does not explicitly compare this tool to siblings. Usage guidelines for tool selection are implied rather than stated. The agent can infer when to use this tool (to get skill content) vs list_skills (to list skills), but no direct alternatives are mentioned.

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

get_token_statsA

Show estimated MCP token usage. Default mode: "summary" returns per-tool counts, session totals, and top-5 historical large calls (~250-400 tok). mode: "detail" adds hot queries, content-hash dupes, chunking adoption, and cache-bypass rate (~1-1.5K tok). Itself cache-exempt and not token-logged.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	summary (default) or detail

TDQS

A4.7/5.0

Behavior5/5

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

The description explicitly states the tool is cache-exempt and not token-logged, which is critical behavioral information beyond the lack of annotations. This fully compensates for missing 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?

Three sentences efficiently convey purpose, modes, behavior, and output details without redundancy or unnecessary words.

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?

Given no output schema, the description adequately explains what each mode returns, making it complete for the tool's diagnostic purpose.

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?

Schema covers 100% of the parameter with enum. Description adds value by explaining the output differences between modes and approximate token costs, surpassing the baseline of 3.

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 displays estimated MCP token usage, specifies two modes with distinct content, and distinguishes itself from sibling tools that serve different purposes.

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?

It explains when to use each mode (summary for overview, detail for in-depth), but lacks explicit guidance on when not to use it or alternatives. However, sibling tools are unrelated, so context is adequate.

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

list_agentsA

List all available platform agents with name, description, and model. Use this first; then call get_agent for full details on a specific agent.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior3/5

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

No annotations exist, so the description must carry full burden. While it correctly implies a read-only operation, it omits details about pagination, ordering, rate limits, or whether the list is comprehensive. The description is adequate but not rich.

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, complete sentence followed by a concise usage note. It is front-loaded with purpose and wastes no words.

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?

The description covers the tool's core function and suggests a follow-up action. With no output schema, it could hint at the return format or limits, but for a simple list tool it is sufficiently complete.

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?

The input schema has no parameters (100% coverage), so the description need not add parameter details. However, it could have mentioned that no input is required. The absence is not a flaw given zero 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 explicitly states 'List all available platform agents with name, description, and model,' which clearly identifies the verb, resource, and returned fields. It also distinguishes from sibling tool 'get_agent' by suggesting a usage sequence.

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

Usage Guidelines5/5

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

The description provides explicit guidance: 'Use this first; then call get_agent for full details on a specific agent.' This clearly indicates when to use this tool and when to switch to an alternative.

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

list_context_guidesA

List all topical context guides (service-mesh, monitoring, networking, etc.)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states the tool lists guides, without disclosing behavioral details such as whether it's read-only, requires authentication, has pagination, or any side effects.

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 with no redundancy. It is front-loaded with the action and resource.

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?

The tool has no output schema, so the description should explain what the response contains (e.g., IDs, names, descriptions). It does not, leaving the agent unaware of the return structure.

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?

With zero parameters, the description adds value by clarifying that the tool returns 'all' guides, which sets expectations for scope. Baseline is 4 for 0-param tools.

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 lists all topical context guides, with examples like service-mesh, monitoring, etc. It distinguishes from siblings like skills and references by specifying 'context guides'.

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 a broad listing use case but does not specify when to use this over alternatives like get_context_guide (for a single guide) or search_memory. No explicit exclusions or context provided.

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

list_memoryA

List this engineer's LOCAL/PRIVATE personal-memory entries (name + category + one-line summary). Memory is machine-specific and gitignored — never shared. Use get_memory to fetch one, search_memory to find by keyword.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully discloses critical behavioral traits: 'LOCAL/PRIVATE', 'machine-specific', 'gitignored — never shared'. This informs the agent about locality, privacy, and persistence, adding value beyond the empty schema.

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 sentences, extremely concise, with immediate purpose and no fluff. Every sentence earns its place by explaining what the tool does, its scope, and alternative tools.

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?

Given the tool's simplicity (0 params, no output schema), the description provides enough information: what fields are returned, the scope (local/private), and ties to related tools. It fully covers the context needed for correct usage.

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?

The schema has 0 parameters, so schema coverage is 100%. Baseline for 0 params is 4, and the description adds no parameter information since none exists. No further compensation needed.

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 'List' and the resource 'personal-memory entries', specifying the returned fields (name, category, one-line summary). It distinguishes itself from sibling tools by mentioning get_memory and search_memory.

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 explicitly says when to use alternatives ('Use get_memory to fetch one, search_memory to find by keyword'), providing clear guidance. It implies this tool is for listing all entries, but lacks explicit 'when not to use' direction, though still strong.

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

list_referencesA

List all shared reference files (cluster contexts, environment map, port conventions, etc.)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It notes that the tool lists 'shared reference files' (implying a read operation), but does not mention whether authentication is required, if results are paginated, or any other behavioral context. Minimal disclosure beyond the obvious.

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 sentence that is front-loaded and concise. It includes examples for clarity without any unnecessary words. Every part earns its place.

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?

Given the tool's simplicity (no parameters, no output schema), the description is adequate but not fully complete. It does not describe the return format or any pagination behavior. For a list tool, an agent might benefit from knowing what fields are returned (e.g., names, IDs). However, the minimal description passes for a trivial tool.

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?

The tool has 0 parameters, so the baseline score is 4. The schema coverage is 100% trivially. The description does not add parameter information because none exists. No deduction needed.

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?

Description clearly states the tool lists all shared reference files, with specific examples (cluster contexts, environment map, port conventions). The verb 'list' and resource 'shared reference files' are specific, and there is no ambiguity. It distinguishes from sibling tools like get_reference (which retrieves a specific reference) and list_memory (different resource type).

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?

Usage is implied: use when you need an overview of all available reference files. However, there is no explicit guidance on when not to use it or alternatives. The description does not mention that for a specific reference, get_reference should be used, or how this differs from search_platform_knowledge.

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

list_skillsB

List all available platform skills with name and description

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose behavior such as pagination, ordering, or performance characteristics. For a list operation, these details are relevant but missing.

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 sentence that directly states the purpose. It is appropriately sized and front-loaded with essential information, with no wasted words.

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 description covers the basic purpose but lacks details about the return format or any prerequisites. Given no output schema and simple input, it is minimally adequate but could be more complete regarding the result structure.

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 no parameters, so the description does not need to add meaning beyond the schema. With 100% schema coverage and zero parameters, this dimension is satisfied.

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 'List all available platform skills with name and description', which is a specific verb+resource. It implicitly distinguishes from 'get_skill' (which would retrieve a single skill), but does not explicitly differentiate from other list tools in the sibling set.

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 guidance on when to use this tool versus alternatives like 'list_references' or 'list_memory'. The description implies a simple overview purpose but lacks explicit when/when-not instructions.

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

search_memoryA

Full-text search restricted to this engineer's LOCAL/PRIVATE personal-memory tree (project/feedback/reference/user notes). Use when you recall having a personal lesson but not its exact name. For shared platform knowledge use search_platform_knowledge instead.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query
`max_results`	No	Maximum results to return (default: 10)

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states the tool is a read-only search and specifies the scope, but does not describe the response format, pagination, or any potential limitations. The description is adequate but lacks detail beyond the core behavior.

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 sentences, front-loaded with scope and purpose, and contains no fluff. Every sentence is relevant and 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?

The tool is simple with only two parameters and no output schema. The description adequately covers the tool's purpose, scope, and usage context. However, it could be more complete by briefly mentioning what the response contains (e.g., list of matching memory items). Nonetheless, it is fairly complete for its 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 coverage is 100%, with each parameter having a description. The tool description does not add any additional meaning or context to the parameters beyond what is in the schema, so baseline 3 is appropriate.

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 performs full-text search restricted to the engineer's local/private personal-memory tree, specifying content types (project/feedback/reference/user notes). It distinguishes from the sibling search_platform_knowledge by scope and audience.

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

Usage Guidelines5/5

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

The description explicitly says to use this tool when recalling a personal lesson but not its exact name, and directs users to search_platform_knowledge for shared platform knowledge. This provides clear when-to-use and alternative guidance.

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

search_platform_knowledgeB

Full-text search across all platform knowledge: skills, agents, references, context guides, and CLAUDE.md files

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query
`max_results`	No	Maximum results to return (default: 10)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It only says 'full-text search', which suggests read-only behavior, but does not disclose performance characteristics, authentication requirements, or scope limitations (e.g., whether it searches all files or is workspace-specific).

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 that efficiently conveys the tool's purpose without unnecessary words or structure.

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?

For a search tool that returns results from multiple knowledge sources, the description lacks details about the return format, ordering, or pagination. Since there is no output schema, the agent may need more context to interpret results correctly.

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 coverage is 100% (both parameters have descriptions in the schema). The description adds context about the types of knowledge being searched, but does not provide additional meaning beyond the schema's existing descriptions for 'query' and 'max_results'.

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's purpose: 'Full-text search across all platform knowledge', listing specific types (skills, agents, references, context guides, CLAUDE.md files). This distinguishes it from sibling tools that list or retrieve individual items.

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?

The description implies using this tool for searching platform knowledge but provides no explicit guidance on when to use it versus alternatives like search_memory, nor does it mention prerequisites or exclusions.

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.

13 tool updatesv0.1.0Jul 29, 2026
- First observedget_agent
- First observedget_context_guide
- First observedget_memory
- First observedget_reference
- First observedget_skill
- First observedget_token_stats
- First observedlist_agents
- First observedlist_context_guides
- First observedlist_memory
- First observedlist_references
- First observedlist_skills
- First observedsearch_memory
- First observedsearch_platform_knowledge

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct resource and action (list vs. get vs. search) with no overlapping purposes. For example, list_skills and get_skill are clearly separated, and search_memory is distinct from search_platform_knowledge.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., list_skills, get_reference, search_memory). The only minor deviation is get_token_stats, but token_stats is a noun phrase, so it still fits the pattern.

Tool Count5/5

With 13 tools covering skills, references, memory, context guides, agents, search, and token statistics, the count is well-scoped for a platform knowledge agent. Each tool serves a specific purpose without unnecessary redundancy.

Completeness5/5

The tool set provides comprehensive read access to all documented knowledge types (skills, references, memory, context guides, agents) and includes both listing and detailed retrieval, plus cross-cutting search and token usage stats. No obvious gaps for the stated purpose of exploring platform knowledge.

Maintenance

ActivityMaintained

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
KodyOAuth
io.github.kentcdodds
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2514
JFrog Remote MCP Server
io.github.jfrog
MCP Server for JFrog, providing tools for development and artifact management.
Developer Tools CI/CD & DevOps Cloud Platforms
215

Related MCP Servers

Friday MCP Server
Search File Systems Developer Tools
JeremyLakeyJr
A
license
B
quality
D
maintenance
A standalone MCP server that enables research (web search, URL fetch, news), workspace management (file operations, command execution), and self-extension via markdown-based skills.
Updated 4 months ago (2026-04-26 05:51 UTC)
21
MIT
mcp-service
Developer Tools Agent Orchestration
logus2k
F
license
Not graded
quality
B
maintenance
Dual-interface MCP server that exposes declarative tools and reusable skills via standard MCP protocol and provides a REST API for authoring them.
Updated 8 days ago (2026-08-29 21:58 UTC)
-
SkillShare MCP Server
Developer Tools Knowledge & Memory
Aniket-think41
A
license
Not graded
quality
A
maintenance
An MCP server that enables AI agents to interact with the SkillShare registry, including searching, reading, creating, and managing resources like skills, MCP configurations, and notes.
Updated 2 months ago (2026-07-08 06:11 UTC)
MIT
mcp-agent-bridge
Autonomous Agents Communication Knowledge & Memory
xfajarr
A
license
Not graded
quality
D
maintenance
A local MCP server that provides shared, real-time context across multiple AI agents via WebSocket and MCP resource notifications, enabling collaborative workspaces, memory, tasks, and messaging.
Updated 5 months ago (2026-03-26 16:28 UTC)
15
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/chris-dare-dev/agent-kit'

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

agent-kit

Design rules

⚠️ The rebuild rule — read before editing src/

Architecture

MCP tools (17)

Quick start

Supported platforms

Testing

Layout

Provenance

Requirements

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

⚠️ The rebuild rule — read before editing `src/`