quarry

Server Quality Checklist

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

Latest release: v2.1.0
Disambiguation5/5
Each tool targets a distinct operation: status reports database health, list enumerates entities, find searches, ingest and remember add content via different sources, show retrieves document details, delete removes data, register/deregister/sync manage directory registrations, and use switches databases. No two tools have identical or ambiguous purposes.
Naming Consistency4/5
The tool names are primarily verb-based (status, list, find, ingest, remember, show, delete, use) with compound names following verb_noun pattern (register_directory, deregister_directory, sync_all_registrations). The mix is consistent in style and readable, though not all tools follow the exact verb_noun convention.
Tool Count5/5
11 tools is well within the ideal range. Each tool covers a necessary aspect of knowledge base management: ingestion, search, retrieval, deletion, directory sync, and database switching. No redundant tools.
Completeness4/5
The tool surface covers core CRUD and lifecycle operations: add (ingest, remember, register_directory, sync), read (find, show, list), delete (delete, deregister_directory), and database management (use, status). Minor gaps include lack of a direct file upload tool (requiring directory registration) and no explicit update tool, but overwrite flags and sync_all_registrations partially address these.
Average 4.3/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 150 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a key trait: 'Returns immediately — the daemon records the registration in the background.' However, it omits other behavioral details such as idempotency, permission requirements, or error handling, leaving gaps in transparency.
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 front-loaded: first sentence states the action, second explains the asynchronous behavior, and the Args section lists the parameters. Every sentence carries necessary information with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (two params, one optional) and the presence of an output schema, the description adequately covers the tool's purpose, key behavior, and parameters. It might benefit from an example or note on prerequisites, but for a simple registration tool it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining both parameters: directory is an absolute path, and collection defaults to the directory name if empty. This adds meaningful semantics beyond the raw schema types and titles.
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 states a specific verb ('Register') and resource ('a directory') with a clear purpose ('for incremental sync'). It distinguishes from sibling tools like deregister_directory (opposite operation) and sync_all_registrations (bulk sync action).
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 explicit guidance is provided on when to use this tool vs alternatives. The description explains the asynchronous behavior but does not mention when registration is appropriate or how it relates to siblings like ingest or remember. Usage context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose safety and side effects. It does not explicitly state that the tool is read-only, nor does it describe error handling or authorization requirements. The description only maps argument values to outputs, leaving a significant transparency gap.
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, starting with the main purpose and then detailing arguments and conditional behavior. It is efficient with no redundant content, and the use of a list for arguments improves readability. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists but does not describe parameters; the description covers both operational modes (metadata vs page text) and the default/edge case (page_number 0). However, it omits error conditions and any prerequisites, making it slightly incomplete for a contextually rich tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It provides meaningful explanations for document_name (with example), page_number (1-indexed, 0 means metadata), and collection (optional scope), adding clarity beyond the raw schema. This is solid but could offer more examples or constraints.
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 shows document metadata or page text, using a specific verb and resource. It internally distinguishes two modes (with/without page_number) and is distinct from siblings like 'list' or 'status' by its focus on individual document details.
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 by the conditional behavior (without vs with page_number), but it does not explicitly state when to prefer this over sibling tools like 'list' or 'find', nor does it provide exclusions. No alternatives are mentioned, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key async trait: 'Returns immediately — the daemon removes chunks in the background.' However, it does not mention irreversibility, permissions, or what exactly happens when deleting a collection, leaving gaps for a destructive 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 compact and well-structured: a clear first sentence, a behavioral note, and a concise Args block. Every line contributes useful information without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple destructive tool with 3 parameters and an output schema present, the description covers the core behavior, parameters, and async processing well. It doesn't address edge cases like idempotency or nonexistent names, but the output schema can provide return details. Minor gaps prevent a 5.
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%, but the description fully compensates by explaining each parameter with semantics and constraints: 'name' is the document/collection name, 'kind' is document/collection, and 'collection' is optional and only for documents. This goes well beyond the schema's bare titles and defaults.
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 verb and resource: 'Delete indexed data for a document or collection.' It is specific and distinguishes itself from sibling tools like 'list' (which lists) and 'ingest' (which adds data).
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 when deletion is needed, and the Args section adds parameter-level guidance (e.g., 'collection' only for kind='document'). However, it does not explicitly note when to prefer this over alternatives or any exclusions, such as handling of missing names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the hybrid search algorithm (RRF, vector, BM25) and its rationale, which is a behavioral trait. However, with no annotations provided, it does not explicitly state that the operation is read-only or mention any side effects, though 'search' implies non-destructive behavior. It also does not mention limitations like only searching already-indexed documents, which is a constraint but not fully explicit.
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: a concise summary, a mechanism explanation, and a clean Args list. Every sentence earns its place, the format is consistent with the schema, and it is neither too long nor too short. It front-loads the purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is highly complete for a search tool: it explains purpose, algorithm, and all parameters, and the existing output schema covers return values. The main gap is the lack of explicit usage guidance versus siblings, which prevents a perfect score, but given the complexity and schema coverage, this is a minor omission.
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 carries the full burden for parameter semantics. It compensates exceptionally by documenting all 8 parameters with clear meanings, defaults, max limits, and examples (e.g., agent_handle 'rmh', memory_type 'fact'). This is far beyond the bare 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 clearly states the tool's purpose: 'Search indexed documents using hybrid semantic + keyword search.' It specifies the search mechanism (vector similarity + BM25 via RRF) and distinguishes itself from sibling tools like 'list' or 'show' through its search-focused verb and detailed method.
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 how the search works and the available filters, but it does not explicitly state when to use this tool versus alternatives like 'list' or 'show'. Use is implied by the tool's name and purpose, but no exclusions or direct alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the categories of returned information, which implies a read-only operation, but does not explicitly state that it has no side effects or describe response format. For a low-risk status tool this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the action and includes no filler. Every word adds value.
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, a present output schema, and a simple status endpoint, the description fully covers the necessary context. It states what data is available, and the output schema handles return-value details.
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, so there is no parameter ambiguity. Per rubric, the baseline for 0 params is 4; no additional description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and names the resource 'database status', explicitly listing content (document/chunk counts, storage size, model info). This clearly distinguishes it from sibling tools like 'list' or 'show' by focusing on system metrics rather than data tuples.
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?
No explicit when-to-use or alternative recommendations are provided. The usage is implied by the tool's name and description—if you need database health metrics, use this—but no exclusions or comparisons to siblings are given.
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 takes on the full burden. It discloses key behavioral details: synchronous removal count, background chunk purge, and error on unknown collection. However, it does not explicitly warn that default keep_data=false leads to data deletion, which is a notable safety gap. Still, it goes beyond a minimal description.
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 clear one-line purpose, followed by key behavioral notes, then Args. Every sentence adds value with no redundancy. It is efficiently front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema, the description does not need to explain return values, but it still mentions the removed-file count and background purge for clarity. It covers error behavior and parameter usage. It lacks mention of prerequisites (e.g., collection must already be registered), but that is implied by the error behavior. Overall, it is sufficiently complete for a two-parameter 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?
The schema provides only titles for the two parameters, so the description's Args section fully compensates. It explains 'collection' as the name to deregister and clarifies that 'keep_data' preserves indexed data when true, implying deletion when false. This adds meaningful semantics beyond the raw 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 states 'Remove a directory registration' with a specific verb and resource, making it clear this tool deregisters a directory. It distinguishes itself from siblings like 'register_directory' and 'delete' by focusing on registration removal. The first line is direct 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 purpose implies usage for deregistering directories, and it mentions error behavior for unknown collections, but it does not explicitly compare with alternatives such as 'delete' or 'register_directory'. No clear 'when to use' vs 'when not to use' guidance is provided beyond the basic verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that 'collection' only applies to 'documents,' which is useful conditional behavior. However, it does not mention other behavioral traits such as read-only nature, pagination, ordering, or potential side effects. For a listing tool, this is adequate but not comprehensive.
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 front-loaded with the main action, followed by a neatly structured Args section. Every sentence provides necessary information, with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not explain return formats. It adequately covers the tool's flexibility (various kinds and optional filter) and is sufficiently complete for a listing operation. It lacks details on pagination or ordering, but these are not always required and are likely captured by the output schema.
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 schema has 0% description coverage, but the description compensates fully by defining allowed values for 'kind' ('documents', 'collections', 'databases', 'registrations') and explaining the conditional behavior of 'collection' (only for kind='documents'). This adds significant meaning beyond the bare schema properties.
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 begins with 'List documents, collections, databases, or registrations,' clearly stating the tool's function with a specific verb and resource types. This distinguishes it from sibling tools like 'find' and 'show' by focusing on enumeration rather than search or detail retrieval.
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 provides a clear context for when to use the tool: whenever you need to list any of the four resource types. It does not explicitly exclude alternatives or mention when not to use it, but the purpose is sufficiently clear to guide basic usage. The condition on the 'collection' parameter adds some contextual guidance.
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 the transparency burden. It discloses a critical asynchronous behavior: 'Returns immediately — the daemon runs the sync in the background.' It also states the operations included (ingest new/changed, remove deleted), though it omits failure and idempotency details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the tool's function, the second explains the asynchronous return behavior. Every word earns its place with no 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?
For a no-argument, fire-and-forget sync tool, the description covers the purpose, scope, and the key background execution behavior. The output schema exists, so return values do not need explanation, and sibling status tool covers follow-up queries.
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, so no additional parameter documentation is needed. The baseline of 4 applies, and the description does not need to compensate for missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Sync'), identifies the resource ('all registered directories'), and clarifies the scope with 'ingest new/changed, remove deleted.' This clearly distinguishes it from sibling per-directory tools like register_directory and deregister_directory.
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 batch use for all registered directories and clarifies its operations, but it does not explicitly state when to prefer this over sibling tools such as ingest or register_directory, nor does it mention exclusions or alternatives.
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 provided, the description carries the full burden of disclosing behavior. It does well by stating that it 'Returns immediately — the daemon indexes in the background,' and mentions smart sitemap discovery, single-page fallback, and why no in-process file loader exists (daemon owns the filesystem). It omits details like authentication or failure modes, but the key behavioral traits are disclosed.
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. The first sentence states the core purpose, followed by a few clarifying lines and a parameter breakdown. No words are wasted, and the essential information 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?
For a tool with no annotations, the description covers the essential dimensions: purpose, usage, behavior, and parameters. The existence of an output schema precludes the need to describe return values. The description is sufficiently complete for an agent to decide when and how to invoke 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?
The schema description coverage is 0%, so the description must compensate. The 'Args' section does exactly that by adding meaning to each parameter: source ('HTTP(S) URL'), overwrite ('replace existing data'), and collection ('Auto-derived if empty'). This fully bridges the gap left by the bare 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 clearly states the tool's action ('Ingest an HTTP(S) URL into the knowledge base') with a specific verb and resource. It also distinguishes itself from sibling tools by explicitly saying 'For local files and directories, use register_directory + sync_all_registrations', making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for HTTP(S) URLs) and when to use alternatives (for local files and directories, naming the exact sibling tools). This is a clear 'when-to-use vs. when-not-to' instruction that goes beyond mere implication.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool scrubs secrets/PII, returns immediately while indexing in the background, and that overwrite replaces existing data. These are important behavioral traits beyond what the schema reveals.
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 clear intro, usage note, behavioral note, and an Args list. Every section earns its place; there is no fluff. The length is appropriate given the 8 parameters and the need to convey background indexing and PII scrubbing.
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 (8 params, background behavior, sibling alternatives), the description covers all critical aspects: purpose, alternatives, return semantics, data handling, and parameter meanings. It is complete enough for an agent to select and invoke it 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?
Schema description coverage is 0%, so the description's Args section is the only source of parameter meaning. It adds value for 'overwrite' ('If true, replace existing data'), 'format_hint' (lists options), and 'memory_type' (lists classifications). However, several parameters like 'content' and 'document_name' only restate their names, so the compensation is not complete.
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 starts with a specific verb and resource: 'Remember inline text content: chunk, embed, and index for search.' It clearly distinguishes itself from the sibling 'ingest' by stating 'Use this instead of ingest when you have the text content directly.' This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this instead of ingest when you have the text content directly (e.g., clipboard, API response, or sandbox-uploaded files in Claude Desktop).' It names the alternative tool and gives concrete example scenarios, fulfilling the guideline dimension thoroughly.
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?
Without annotations, the description carries the full burden and fully discloses the persistent side effect: 'will target the selected database's daemon until changed again.' It also reveals the conditional no-op behavior under remote targets, which is a critical behavioral nuance beyond a simple switch.
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 front-loaded purpose, followed by behavioral scope, a limitation caveat, and a clear Args block. Every sentence contributes unique information—no filler or redundancy—making it appropriately sized for the tool's simplicity.
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?
For a one-parameter tool with an output schema present, the description is complete: it states the operation, the effect on subsequent tools, the local-only limitation, and the parameter format. Return values are presumably covered by the output schema, so no additional explanation is needed.
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 schema provides only a 'string' type for 'name' with no description, leaving 0% coverage. The description compensates by explaining: 'Database name (e.g., 'coding', 'work'). Use 'default' for the default database,' adding examples and special-case instructions that make the parameter's meaning and usage unambiguous.
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 opens with 'Switch to a different named database for subsequent operations,' which is a specific verb and resource that clearly distinguishes this tool from siblings like find, ingest, or sync. It establishes the tool as a context setter, not a data operation, and the title 'use' is adequately expanded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that 'All tools (find, ingest, sync, etc.) will target the selected database's daemon until changed again,' providing clear guidance on when to invoke it. It also notes the exclusion: 'while a remote target ... is active, the remote daemon is fixed to its own database and this has no effect,' and suggests using list(kind='databases') to inspect the current state.
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:

[![quarry MCP server](https://glama.ai/mcp/servers/punt-labs/quarry/badges/card.svg)](https://glama.ai/mcp/servers/punt-labs/quarry)

Score Badge

Copy to your README.md:

[![quarry MCP server](https://glama.ai/mcp/servers/punt-labs/quarry/badges/score.svg)](https://glama.ai/mcp/servers/punt-labs/quarry)

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/punt-labs/quarry'

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