Which integrations are available for this server?

Provides an embeddings backend using a local Ollama instance for generating vector representations of text chunks. Provides an embeddings backend using OpenAI's API for generating vector representations of text chunks.

How do I use profile-project?

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., "@profile-project init this project" 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.

profile-project

by goosefly99

Overview Schema Related Servers Score Discussions

Python

Local

profile-project

A self-contained Claude Code plugin that runs a fixed, agent-driven DAG to profile a project — source code, in-repo docs, transcripts, notes, and external references — and emit three durable deliverables:

Agent-facing context pages (profile/context/) — dense, multi-page markdown for fast machine consumption.
A human/developer guide (profile/guide/) — readable narrative documentation for onboarding.
A local queryable vectorstore over both, answered via pp_query.

It ships as one Python FastMCP server (profile_project) plus a skill suite and slash commands. It runs per-session over stdio, needs no Docker and no mandatory Ollama, and never writes a single local artifact to a target project until that project is explicitly initialized via /profile-project:init.

Installation

profile-project is launched by Claude Code over stdio. The host runs the server with:

uv run --directory ${CLAUDE_PLUGIN_ROOT} python -m profile_project

uv syncs the environment from the root pyproject.toml, then runs the package as a module. You need only uv and Python ≥ 3.11 on the machine.

Dependency extras

The base install is light. Backends are optional extras (a missing extra for a selected backend is a warn + disable, never a crash):

Extra	Pulls in	Required for
(base)	`mcp`, `pydantic>=2`, `pydantic-settings>=2`, `tiktoken`, `structlog`, `httpx`	server, config, DAG, chunking, ollama (httpx only)
`[chroma]`	`chromadb`	ChromaDB local store
`[pinecone]`	`pinecone>=9.1.0`	Pinecone remote store
`[openai]`	`openai`	OpenAI embeddings
`[local-embeddings]`	`sentence-transformers`	sentence-transformers (the default embedder)
`[ollama]`	(httpx only — already base)	Ollama embeddings
`[all]`	union of the above	everything

Recommended default backend. The recommended path is sentence-transformers (local, offline after first model pull, dim 384) for embeddings + chromadb (local on-disk) for storage — no Docker, no external service, no API key. For a manual/dev checkout, install it with [local-embeddings] and [chroma] (or [all]):

uv pip install -e ".[local-embeddings,chroma]"

Enabling the vectorstore on a plugin install (opt-in)

The server always starts on a plain install, but the vectorstore is off by default: the stdio launch command (uv run … python -m profile_project) installs only the base dependencies, so the embedding + store libraries are absent and the conflict matrix warns + disables the vectorstore (the DAG still runs and produces both guides). This keeps cold start fast — sentence-transformers pulls in torch (~2 GB), which is too heavy to download on every launch.

To turn the vectorstore on, add the extras to the launch command in the installed plugin's .mcp.json (${CLAUDE_PLUGIN_ROOT}/.mcp.json):

{
  "mcpServers": {
    "profile-project": {
      "command": "uv",
      "args": ["run", "--extra", "local-embeddings", "--extra", "chroma",
               "--directory", "${CLAUDE_PLUGIN_ROOT}", "python", "-m", "profile_project"]
    }
  }
}

The first launch after adding the extras resolves and downloads them (slow, one time); later launches reuse the synced environment. Swap in --extra pinecone / --extra openai (or --extra all) for the corresponding backends. Every vectorstore backend needs at least one extra; only ollama embeddings run on the base install (httpx is a base dependency) — but a store backend (chroma or pinecone) is still required.

Related MCP server: Claude Persistent Memory

Initialization

The plugin must be explicitly initialized per project before it writes any local artifact — this gate is enforced in the MCP server, not just the skill.

/profile-project:init

init runs read-only diagnostics (pp_config_validate, pp_vectorstore_check), collects/confirms config, validates that required secrets exist in your environment, then calls the server tool pp_init_project, which transactionally writes .profile_project_config.json, the gitignored .profile_project/ tree, the .initialized stamp, and the .gitignore entry. Until init succeeds, every mutating tool refuses with a structured not_initialized error and writes nothing.

Re-run /profile-project:init any time to reconfigure (idempotent); use /profile-project:init --reinit to overwrite/reset existing run artifacts.

Usage

Command	What it does
`/profile-project:init`	Initialize the project (the only path that creates initial artifacts)
`/profile-project:profile`	Run the full profiling DAG
`/profile-project:status`	Show run/phase status and what's next
`/profile-project:query`	Ask a semantic question over the profile
`/profile-project:navigate`	Browse generated pages and per-phase artifacts
`/profile-project:refresh`	Incrementally refresh an existing profile

A typical first run: /profile-project:init → /profile-project:profile → /profile-project:query "how is config resolved?". The generated profile/context/ and profile/guide/ directories are committable project artifacts.

Configuration

Configuration is layered. Project JSON overrides env (the inverse of agent-knowledgebase): .profile_project_config.json at the project root takes precedence over PROFILE_PROJECT_* environment variables, which act as defaults.

Precedence (highest to lowest): init kwargs → project JSON → env → .env → file secrets → field defaults.

Secrets are environment-only. PROFILE_PROJECT_OPENAI_API_KEY and PROFILE_PROJECT_PINECONE_API_KEY are modeled as SecretStr, read only from the environment, and are never written to .profile_project_config.json (the JSON source hard-rejects forbidden keys), never stamped into chunk metadata, and never logged (masked). .env.example documents the env vars and contains no real values.

Common env vars (full table in .env.example):

Env var	Maps to	Default
`PROFILE_PROJECT_DEFAULT_EMBEDDINGS_METHOD`	`embeddings.method`	(unset → init prompts)
`PROFILE_PROJECT_VECTORSTORE__BACKEND`	`vectorstore.backend`	(unset → init prompts)
`PROFILE_PROJECT_CHROMADB__PATH`	`vectorstore.chromadb.path`	`.profile_project/chroma`
`PROFILE_PROJECT_OPENAI_API_KEY`	`openai_api_key` (secret)	(none)
`PROFILE_PROJECT_PINECONE_API_KEY`	`pinecone_api_key` (secret)	(none)

Embeddings. The default embedder's canonical geometry id is sentence-transformers/all-MiniLM-L6-v2@hf-fp32 (stamped per chunk so a query-time rebuild rejects a mismatched embedder rather than returning meaningless scores). OpenAI and Ollama are alternatives selected via config.

Pinecone uses an EXISTING index only. The plugin never creates a Pinecone index. You supply an existing index ref + embeddings_model; at connect time the store validates index.dimension == effective_embedding_dim and refuses on mismatch. A missing index ref, missing key, or dimension mismatch warns + disables the vectorstore (the DAG still runs and produces the guides).

Troubleshooting

"not_initialized" on a tool call. Run /profile-project:init first. The gate is server-enforced; no mutating tool writes before initialization.
Vectorstore silently disabled. Run pp_config_validate and pp_vectorstore_check; a missing extra ([chroma]/[pinecone]/[openai]/[local-embeddings]), missing API key, missing Pinecone index ref, unreachable Ollama host, or dimension mismatch all warn
- disable rather than crash. The warning names the exact cause. On a plugin install the most common cause is that the launch command installs only base deps — see Enabling the vectorstore on a plugin install above to add the --extra flags.
pp_query returns index_disabled / index_empty. The vectorstore is off, or no vectors have been built yet — run /profile-project:profile (which runs build_vectorstore) or check pp_index_status.
"project_root_moved". The project was initialized for a different absolute root. Run /profile-project:init --reinit.
Garbled JSON-RPC / protocol errors. Nothing may be written to stdout under stdio transport — all logs go to stderr only. If you patched the server, ensure no print() reaches stdout.
First profiling run is slow. sentence-transformers downloads all-MiniLM-L6-v2 once; subsequent runs are offline.

Security & hygiene

Secrets are env-only (SecretStr): never in .profile_project_config.json, never in chunk metadata, never logged (masked).
.profile_project/ is gitignored (local store, run-state, artifacts, cache, .initialized). The profile/ guides are intentionally committable.
No user-specific absolute paths are written to tracked config; profile.root_dir is resolved at runtime, never persisted.
stdio hygiene: logs go to stderr only; stdout stays clean for JSON-RPC framing.
No remote provisioning: Pinecone indexes are never auto-created, so the plugin cannot silently incur cost.

Available Tools

27 tools

pp_add_sourceD

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No
`path_or_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_complete_phaseD

ParametersJSON Schema

Name	Required	Description	Default
`phase`	Yes
`run_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_config_getD

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_config_pathD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_config_setD

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes
`value`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_config_showD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_config_validateD

ParametersJSON Schema

Name	Required	Description	Default
`project_path`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_discover_sourcesD

ParametersJSON Schema

Name	Required	Description	Default
`persist`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_fail_phaseD

ParametersJSON Schema

Name	Required	Description	Default
`error`	Yes
`phase`	Yes
`run_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_get_sourceD

ParametersJSON Schema

Name	Required	Description	Default
`source_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_index_buildD

Chunk -> embed -> upsert agent pages into the store (§9.3/§11).

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1.6/5.0

Behavior1/5

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

With no annotations, the description must disclose behavioral traits. It only says 'upsert' implying modification, but omits details on whether it is destructive, idempotent, or requires specific permissions. No information about rate limits or side effects is given.

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

Conciseness2/5

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

The description is extremely concise, but the arrow notation is not standard and clarity is sacrificed. It lacks structure and meaningful sentences.

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

Completeness1/5

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

Given one optional parameter and an output schema, the description should provide more context about the tool's operation and output, but it is nearly absent. The references to sections (§9.3/§11) are unhelpful without further explanation.

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

Parameters1/5

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

Schema coverage is 0% and the description does not explain the single parameter 'run_id'. The parameter's purpose and expected values are completely undocumented.

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

Purpose3/5

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

The description indicates a pipeline of chunking, embedding, and upserting agent pages into a store, which outlines the main action. However, the arrow syntax is cryptic and may not be universally understood. It does not clearly distinguish from siblings like pp_index_rebuild, making the precise purpose somewhat ambiguous.

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

Usage Guidelines1/5

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 pp_index_rebuild or pp_index_status. 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.

pp_index_rebuildC

Full geometry-safe re-index (reset + rebuild, §10.4/§11).

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior3/5

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

No annotations are present, so description carries full burden. It mentions 'geometry-safe' and 'reset + rebuild', indicating a destructive but safe operation. However, lacks details on permissions, side effects, or return behavior.

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 sentence, front-loaded with key action and reference. Efficient but could be more structured.

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?

Low schema coverage, no annotations, and a minimal description. The tool has an output schema, but the description doesn't mention it. Incomplete for a tool with one parameter.

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

Parameters1/5

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

Schema coverage is 0%, and the description does not explain the run_id parameter's purpose or effect. With only one optional parameter, this is a critical gap.

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?

Description specifies 'Full geometry-safe re-index (reset + rebuild, §10.4/§11)', clearly stating the action (re-index) and nature (geometry-safe, reset+rebuild). However, it does not differentiate from the sibling tool pp_index_build.

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 vs alternatives like pp_index_build. No when-not or context provided.

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

pp_index_statusC

Store stats. In-handler read-only init guard (§11/§6b.3).

Count-only by design: a status read reuses the warm memoized bundle when one exists, and on a cold process it never constructs the embedder (a full model load for sentence-transformers) — the count comes from a store-only client and the geometry metadata from the prior vectorstore-index artifact.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior4/5

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

The description candidly explains that the tool is read-only, uses caching, avoids loading the embedder module, and details cold vs warm paths. This provides good transparency beyond the lack of annotations.

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

Conciseness2/5

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

The description is verbose and includes obscure cross-references (§11/§6b.3) and jargon ('warm memoized bundle'). It is not front-loaded or easy to parse. Every sentence could be clearer and more concise.

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 presence of an output schema, the description does not need to explain return values, but it could still summarize what the output represents (e.g., count and geometry). The description provides deep internal context but misses a concise summary, making it somewhat incomplete for quick comprehension.

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. The description adds meaningful context about what the tool does (count-only, uses store-only client), which compensates for the absence of parameters. Baseline for zero params is 4.

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

Purpose2/5

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

The description does not explicitly state that 'pp_index_status' retrieves the current index status. It starts with 'Store stats' which is vague, then dives into implementation details. The purpose is implied by the name and context, but not clearly articulated.

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 is given on when to use this tool versus siblings like pp_vectorstore_check or pp_query. The mention of 'in-handler read-only init guard' hints at a specific context but does not contrast with alternative tools.

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

pp_init_projectD

ParametersJSON Schema

Name	Required	Description	Default
`force`	No
`config`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_init_runD

ParametersJSON Schema

Name	Required	Description	Default
`run_parameters`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_list_artifactsD

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_list_runsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_list_sourcesD

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_load_artifactD

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes
`run_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_next_phasesD

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_queryB

Embed query -> vector search -> ranked, attributed hits (§11).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`top_k`	No
`where`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It outlines the core behavioral flow (embed, search, return hits) but omits details like whether the tool is read-only, destructive, or requires authentication. The description is adequate for basic understanding but lacks depth.

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

Conciseness4/5

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

The description is a single, compact sentence that conveys the core pipeline. However, the inclusion of '§11' may confuse agents without context, slightly reducing clarity.

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?

Given the tool's complexity (3 parameters, output schema), the description is woefully incomplete. It does not explain the search behavior, result format, or parameter defaults/options. An output schema exists but is not referenced, leaving the agent under-informed.

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no information about the parameters (query, top_k, where). The agent cannot understand parameter roles, constraints, or usage from the description alone, making it nearly useless for correct invocation.

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 an embedding query followed by vector search, returning ranked and attributed hits. It distinguishes itself from sibling tools (e.g., config, pipeline phases, index building) by focusing on querying a vector store, making its purpose specific and unambiguous.

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

Usage Guidelines3/5

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

The description implies usage for vector search queries but provides no explicit guidance on when to use this tool versus siblings, nor does it mention prerequisites or alternatives. The reference to §11 is obscure and not helpful for an AI agent.

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

pp_retry_phaseD

ParametersJSON Schema

Name	Required	Description	Default
`phase`	Yes
`run_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_run_statusD

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_start_phaseD

ParametersJSON Schema

Name	Required	Description	Default
`phase`	Yes
`run_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_store_artifactD

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes
`phase`	Yes
`run_id`	Yes
`content`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_validate_artifactD

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes
`content`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

pp_vectorstore_checkA

Diagnose vectorstore reachability + dimension (read-only; never writes).

This tool is inherently a dry-run diagnostic: it NEVER constructs the store client and NEVER writes to disk. It runs the §6.5 conflict matrix with two bounded, fail-closed live probes wired in:

C3 (ollama unreachable): a GET to the configured ollama base_url within embed_timeout_seconds; any error/timeout warns + disables.
C4 (Pinecone dimension): a describe_index lookup compared against the effective embedding dimension; a mismatch or any probe failure warns + disables (no index is ever created).

reachable reflects whether the vectorstore survives the conflict matrix (with the above probes folded in): chromadb-local is always reachable; remote/probe-gated backends are reachable only when no disabling conflict fired. dimension is the embedder's effective dimension when it can be built, else None.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output 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 behavior: read-only, no writes, two live probes (C3 and C4), conflict matrix usage, and effect on reachable/dimension outputs. It is highly transparent.

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 front-loaded with a concise summary, then details probes, and finally defines outputs. Every sentence serves a purpose without redundancy.

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 zero parameters and an existing output schema (implied), the description thoroughly explains all behavioral aspects, probe details, and output meaning, making it 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 tool has zero parameters, and schema coverage is 100%. The description adds value by explaining the output fields, which is beyond the minimum baseline of 3, hence 4.

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 diagnoses vectorstore reachability and dimension, and explicitly notes it is read-only. This distinguishes it from other sibling tools like pp_index_status or pp_query.

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 explains the tool is a dry-run diagnostic and never writes, providing clear context. However, it does not explicitly exclude alternative tools or state 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.

Tool Schema Changelog

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

27 tool updatesv0.1.3Jul 29, 2026
- First observedpp_add_source
- First observedpp_complete_phase
- First observedpp_config_get
- First observedpp_config_path
- First observedpp_config_set
- First observedpp_config_show
- First observedpp_config_validate
- First observedpp_discover_sources
- First observedpp_fail_phase
- First observedpp_get_source
- First observedpp_index_build
- First observedpp_index_rebuild
- First observedpp_index_status
- First observedpp_init_project
- First observedpp_init_run
- First observedpp_list_artifacts
- First observedpp_list_runs
- First observedpp_list_sources
- First observedpp_load_artifact
- First observedpp_next_phases
- First observedpp_query
- First observedpp_retry_phase
- First observedpp_run_status
- First observedpp_start_phase
- First observedpp_store_artifact
- First observedpp_validate_artifact
- First observedpp_vectorstore_check

Install Server

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

TDQS

D1.7/5.0

Disambiguation2/5

Many tools have overlapping or unclear purposes, especially without descriptions. For example, pp_run_status, pp_init_run, pp_list_runs are ambiguous; pp_config_path, pp_config_show, pp_config_get, pp_config_set are confusingly similar. Even with partial descriptions, agents would struggle to select the correct tool.

Naming Consistency4/5

All tools use the 'pp_' prefix and snake_case. Most follow a verb_noun pattern (e.g., init_project, list_sources, store_artifact). There are minor deviations like pp_run_status (noun_verb) and pp_next_phases (adjective_noun), but overall the naming is fairly consistent.

Tool Count3/5

27 tools is on the heavier side but not excessive. The server covers multiple sub-domains (config, runs, phases, sources, artifacts, indexing). Some tools could be consolidated (e.g., merging config tools or status tools), but the count is manageable.

Completeness3/5

The tool set covers many lifecycle operations for runs, phases, sources, artifacts, and indexing. However, there are notable gaps: no delete operations for sources, artifacts, or runs; no update operations; and lack of tools for user management or permissions. The domain is partially covered.

Maintenance

ActivitySlowing

ResponsivenessSyncing

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

ContextStream MCP ServerOAuth
io.github.contextstream
Project memory, semantic code search, and grounded agent context.
Knowledge & Memory Code Analysis RAG Systems
141
Umtri
io.umtri
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Code Analysis Knowledge & Memory Software Architecture
1
suma-memory A
io.github.sumanaddanki
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Knowledge & Memory Developer Tools Autonomous Agents
2
AgentDrive A
sh.agentdrive
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Agent Orchestration Developer Tools
202

Related MCP Servers

Axme-codeofficial
Knowledge & Memory Developer Tools
AxmeAI
A
license
Not graded
quality
A
maintenance
Persistent project memory + architectural decisions + pre-execution safety hooks for Claude Code. Local-only storage, multi-repo workspace, automatic knowledge extraction via background auditor.
Updated 18 days ago (2026-08-19 08:01 UTC)
31
14
MIT
Claude Persistent Memory
Knowledge & Memory RAG Systems
MIMI180306
A
license
Not graded
quality
C
maintenance
Gives Claude Code long-term memory that persists across sessions via hybrid BM25 and vector semantic search, with multi-project isolation.
Updated 6 months ago (2026-02-25 10:57 UTC)
11
8
MIT
claude-context-local
RAG Systems Developer Tools Code Analysis
tazhate
A
license
Not graded
quality
C
maintenance
Provides Claude Code with local semantic search and indexing of your codebase using AST-aware chunking and hybrid search, enabling deep code understanding without sending data to the cloud.
Updated 6 months ago (2026-03-18 19:42 UTC)
MIT
MCP Documentation Server
Documentation Access Developer Tools Search
TLazari
F
license
Not graded
quality
D
maintenance
Provides project documentation, database schema, business rules, and search capabilities as context for Claude Code, enabling more accurate code generation and query writing.
Updated 10 months ago (2025-11-07 18:11 UTC)
-

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/goosefly99/profile-project-claude-plugin'

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

profile-project

Installation

Dependency extras

Enabling the vectorstore on a plugin install (opt-in)

Initialization

Usage

Configuration

Troubleshooting

Security & hygiene

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Axme-codeofficial

Latest Blog Posts

MCP directory API