Khiip

Official

by KhiipAI

Overview Schema Related Servers Score Discussions

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct purpose: capturing a URL, fetching a capture, listing captures, semantic recall, refetching dimensions, and checking daemon status. No overlap in functionality.
Naming Consistency4/5
Tools follow a verb_noun pattern with snake_case (e.g., capture_url, get_capture). 'daemon_status' is a noun phrase but still clear and consistent in style. Minor deviation from verb-first naming.
Tool Count5/5
6 tools is well-scoped for a URL capture and retrieval server. Each tool addresses a core operation without unnecessary redundancy.
Completeness4/5
Covers create, read, list, search, and update (via refetch). Missing a delete tool, which is a notable gap for a complete lifecycle, but the core workflows are covered.
Average 4.4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly explains each dimension's behavior: extraction involves a network re-fetch and marking the old capture superseded; re-extract, re-render, media, and wayback all operate in-place. It also states the return value. No contradictions or hidden side effects noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-line summary but includes technical references (ADR-0010, ADR-0009, S42) that may be unnecessary for an AI agent. Some sentences could be more concise without losing clarity.
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 complexity of multiple dimensions and no output schema, the description covers what each dimension does, the parameters, and the return type. It is complete and leaves no major gaps for agent understanding.
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?
Both parameters are well-documented: capture_id is described as 'The capture ULID to refetch' and dimension is explained with a list of allowed values and their defaults. The schema description coverage is 0%, so the description fully compensates.
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: 'Refetch one dimension of an existing capture.' It enumerates the five dimensions with detailed explanations, distinguishing the tool from siblings like get_capture or list_captures.
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 through the dimension descriptions, but there is no explicit guidance on when to use this tool versus alternatives like get_capture (for reading) or capture_url (for initial capture). No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description fully bears the responsibility of disclosing behavior. It details the ranking method (cosine similarity over embed-text composition) and mentions the output includes scores. However, it does not explicitly state that the operation is read-only or has no side effects, which would be helpful for a query tool.
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 concise and well-structured: a brief purpose paragraph followed by structured Args and Returns sections. Every sentence adds value without 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?
The tool has two parameters, no nested objects, and an output schema exists. The description adequately explains the tool's function and return structure. It references an internal ADR, which may not be meaningful to all agents, but overall the description is sufficiently complete.
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?
The input schema has 0% description coverage, so the description must add meaning. It clearly defines 'query' as a natural-language query and 'limit' with range (1-100) and default 10, providing crucial context not present in the schema (which only shows default).
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 the tool performs 'semantic recall over captured payloads by natural-language query', clearly indicating the verb (recall), resource (captured payloads), and method (natural-language query). It distinguishes from siblings like 'capture_url' and 'list_captures', which focus on different operations.
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 explains the tool ranks captures by cosine similarity and returns top-k results, but it does not explicitly specify when to use this tool versus alternatives (e.g., 'list_captures' for exact listing, 'get_capture' for a single capture). No exclusion or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It details that the tool aggregates GET /health and GET /api/v1/meta, and describes return values on success and failure (structured error dict). This is sufficient for a health-check tool. No contradictions with annotations.
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 relatively short and front-loaded with the main function. It uses clear language and includes examples of return values. However, it could be slightly more concise by removing the code block formatting, though it remains efficient and informative.
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 (no parameters, no complexity), the description is complete. It states the purpose, usage context, return values, and error handling. With an output schema present, there is no need to detail return fields further. The description fully equips an agent to use the tool correctly.
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 zero parameters (no properties). The description explains the tool's behavior without needing to describe parameters. According to guidelines, 0 parameters defaults to a baseline of 4. The description adds meaning beyond the schema by explaining what the tool does and returns.
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 function: 'Combined daemon health + metadata'. It specifies that it aggregates two endpoints and lists what information is returned (health status, metadata, version). This distinguishes it from sibling tools like capture_url and list_captures, which handle capture operations. The purpose is 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use the tool: 'Useful as a first call when an agent connects, to confirm the daemon is reachable and to learn what sources + capabilities are available.' This provides clear context for use. While it doesn't explicitly mention when not to use alternatives, the sibling tools' functions (capture-related) imply that this tool is for status checks, making the guidance effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return envelope format on success and structured error dict on failure. It also lists all format options and their effects. However, it does not mention rate limits, authentication needs, or potential side effects, which are minor for a read operation.
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 well-structured with a summary line followed by Args and Returns sections. It is concise yet complete, with no unnecessary words. Every sentence provides essential information, and the most important information (fetching a single capture) is front-loaded.
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 complexity (multiple format options) and the presence of an output schema, the description covers all necessary aspects: purpose, parameters, return format, and error behavior. It is sufficient for an agent to understand and use the tool correctly.
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 description coverage is 0%, so the description must compensate. It fully describes both parameters: capture_id as 'the capture ULID' and format with explicit enumeration of options (json, markdown, vault-frontmatter, legacy-markdown) and default. This adds significant value beyond the schema.
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 'Fetch a single capture by id, in the requested format.' It clearly identifies the verb, resource, and scope, distinguishing it from sibling tools like list_captures (multiple captures) and refetch_capture (re-fetching).
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 does not explicitly state when to use this tool versus alternatives or provide exclusions. It implies usage for retrieving a single capture but lacks explicit guidance on when not to use it or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description discloses ordering (newest first), return format for success and failure, and parameter constraints. It does not mention rate limits or authentication, but for a read-only list operation, this is adequate.
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 cover purpose, parameters, and returns. No filler. Front-loaded with the primary purpose.
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 simplicity (3 optional params, pagination, no annotations), the description fully covers purpose, ordering, all parameters, and return structure. The output schema exists, but the description still adds value by explaining the response format.
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 0%, but the description explains each parameter: source lists allowed values, limit has range (1-500) and default (50), offset has default (0). This adds substantial meaning beyond the schema.
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 captures, newest first.' This clearly identifies the verb (list) and resource (captures), and distinguishes from sibling tools like get_capture (single) and capture_url (creation).
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 optional source filtering and pagination (limit, offset) but does not explicitly state when to use this tool versus alternatives like recall or daemon_status. However, the purpose is distinct enough given sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses dispatching to extractors, storage details, Wayback Machine interaction, idempotency by URL hash dedup, and force_new override, which 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with paragraphs and bullet-like args, but includes return value summary that may be redundant given output schema exists. Slightly verbose but efficient.
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?
Covers key aspects: extraction type, storage tiers, Wayback Machine, idempotency, and output structure. No missing critical details for a capture tool.
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?
With 0% schema coverage, the description fully explains both parameters: url is the URL to capture, force_new overrides dedup with pointer behavior and defaults to false.
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 captures a URL into the Khiip substrate, dispatching to appropriate extractors. It distinguishes from siblings like get_capture and list_captures through its specific action.
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?
Describes idempotency and behavior like Wayback Machine submission, but lacks explicit when-not-to-use compared to siblings. Still provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![khiip MCP server](https://glama.ai/mcp/servers/KhiipAI/khiip/badges/card.svg)](https://glama.ai/mcp/servers/KhiipAI/khiip)

Score Badge

Copy to your README.md:

[![khiip MCP server](https://glama.ai/mcp/servers/KhiipAI/khiip/badges/score.svg)](https://glama.ai/mcp/servers/KhiipAI/khiip)

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/KhiipAI/khiip'

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