@lakehouse/mcp-server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are largely distinct: search_tools is meta, search and ask_question target different retrieval modes, and time_travel tools are clearly separated. Some confusion could arise between search and ask_question since both retrieve information, but descriptions clarify the intent.
Naming Consistency4/5
Most tools follow a verb_noun pattern (get_document, list_documents, upload_document). A few deviate like 'search' (bare verb) and 'time_travel_diff' (noun-heavy), but overall naming is predictable and readable.
Tool Count5/5
With 10 tools, the server is well-scoped. Each tool serves a distinct function within the two core domains (document search/RAG and time-travel on Iceberg), and none feel redundant or unnecessary.
Completeness3/5
The document side covers upload, retrieval, and search but lacks update and delete operations, which are common CRUD gaps. The time-travel features are useful but assume knowledge of tables/snapshots without a listing mechanism; overall the surface is functional but not fully comprehensive.
Average 3.1/5 across 10 of 10 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits 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
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

Behavior2/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 of behavioral disclosure. It does not explicitly state that the operation is read-only, mention required permissions, or describe the behavior when both snapshot_id and as_of_timestamp are provided or omitted. The term 'query' implies read-only but this is not explicitly confirmed.
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 a single sentence, which is concise in length but under-specified. It conveys only the core purpose and omits essential contextual or parameter-related information needed for effective use, making it more under-sized than appropriately concise.
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 the tool has 7 parameters, no annotations, no output schema, and related siblings, the description is grossly incomplete. It does not explain how to specify time (snapshot_id vs timestamp), what filtering options are available, or when to choose this over time_travel_diff or list_snapshots, leaving the agent without adequate information for correct invocation.
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 only 29% (2 of 7 parameters have descriptions), and the description itself adds no parameter details. It does not explain the distinction between snapshot_id and as_of_timestamp, the meaning of where, columns, or limit, or the format of table_name values beyond the schema. With low schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries historical Iceberg data at a snapshot/timestamp, specifying the resource and temporal scope. It partially distinguishes from siblings like time_travel_diff and list_snapshots, but does not explicitly differentiate the querying action from those.
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 provided on when to use this tool versus alternatives such as time_travel_diff or list_snapshots. The description lacks any indication of prerequisites, exclusions, or typical use cases, leaving the agent without decision support.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only mentions the return value (AI answer with source count) but does not disclose whether the operation is read-only, how sources are selected, or any limitations—information an agent would need to invoke it safely.
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 extremely concise, using two short sentences with no filler words. Every word contributes to the core purpose and output, making it appropriately sized for its brevity.
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?
The tool has 3 parameters, no output schema, and no annotations, yet the description provides almost no contextual information. It fails to explain parameter roles, expected input format, or behavior beyond a vague output description, making it incomplete for a complex tool.
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%, so the description must compensate but does not. None of the three parameters (question, model, collection_ids) are explained; even the purpose of collection_ids is left undefined. The description adds no meaningful parameter semantics beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is RAG-based Q&A, which clearly identifies it as a question-answering tool. It distinguishes from sibling search tools by framing it as Q&A rather than generic search, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like search_tools or get_document. No context about scenarios or exclusions is given.
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 carries the full burden of behavioral disclosure. It mentions cursor pagination, which is a useful behavioral trait, but omits other important behaviors such as read-only nature, default limits, ordering, error handling, or permission requirements. This is insufficient for a tool that might be called in critical workflows.
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 extremely concise, with two short sentences that front-load the primary action. There is no filler or redundancy. It earns a high score for brevity, though it trades completeness for conciseness and could benefit from a little more detail.
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 five optional parameters, lack of output schema, and absence of annotations, the description is too sparse to provide complete operational context. It does not explain parameter interactions, return value shape, pagination mechanics, or default behaviors. This is a minimum viable description but leaves significant gaps for an agent to fill.
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 descriptions cover 0% of the five parameters, and the description only says 'with filters' without explaining any parameter meanings. There is no mention of what 'cursor', 'search', 'status', or 'collection_id' represent. The description completely fails to compensate for the lack of schema-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the main action ('List documents') and the resource ('documents'), distinguishing it from sibling tools like get_document or list_collections. The added phrase 'with filters' gives a hint of scope, though it doesn't enumerate specific filter capabilities, which would elevate it to a 5.
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?
There is no explicit guidance on when to use this tool versus alternatives like search or search_tools. The phrase 'with filters' implies some search-like functionality, but there are no exclusions, alternatives, or context cues. The agent is left to infer suitability based on the tool name alone.
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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states that the tool lists snapshots, omitting any details about read-only guarantees, output format, ordering, pagination, or permissions. This lack of transparency is insufficient for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly communicates the core purpose without any waste. It earns its place by combining the action, resource, and context efficiently.
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 the tool has 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what the returned list contains, how parameters affect behavior, or any prerequisites. The description is barely more informative than the tool name itself and fails to provide the context needed for correct invocation.
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?
The input schema has 0% description coverage, and the description adds no meaning to any parameter. It does not explain the limit for controlling result size, the namespace for scope, or the required table_name. The description fails to compensate for the schema's lack of descriptions, leaving parameter semantics entirely ambiguous.
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 'List Iceberg table snapshots for time-travel' clearly states the verb (list) and resource (Iceberg table snapshots) with a specific purpose (time-travel). This distinguishes it from sibling tools like time_travel_query and time_travel_diff, which perform different operations on snapshots.
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 phrase 'for time-travel' implies the usage context—listing snapshots to enable time-travel queries—but it does not explicitly mention when to use this tool versus alternatives. No exclusions or alternative recommendations are provided, so 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?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that documents are auto-chunked and indexed, which are meaningful side effects. However, it omits other behaviors like persistence, async processing, or permission requirements, so it is only partially 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?
The description is a single sentence that is front-loaded with the core action. It contains no filler words, but it is arguably too sparse. Still, as a concise statement, it earns its place effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what content_type is valid for, how collection_id is used, what metadata should contain, or what the return value represents. Only the basic upload intent is covered.
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 tool description does not explain any of the 5 parameters (title, content, metadata, content_type, collection_id). No additional meaning is provided beyond the raw parameter names, so the agent gets no help in constructing correct arguments.
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 'Upload text document' with a specific verb and resource, and adds 'Auto-chunked and indexed' which distinguishes it from read/search tools like get_document and search. This leaves no ambiguity about the tool's primary function.
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 alternatives like get_document, list_documents, or time_travel_query. There are no mentions of prerequisites, exclusions, or context where this tool is preferred.
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 present, so the description carries the full burden. It discloses the hybrid search approach and cursor pagination, but omits details such as whether collection_ids are required, rate limits, or the structure of returned chunks. Some transparency is provided, but it is 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 a single sentence that front-loads the key behavior and output format. There is no filler or redundancy.
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?
With 5 parameters, no output schema, and no annotations, the description is too minimal. It states the basic result type but not the structure of chunks, usage context, or limitations, making it insufficient for fully informed autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, with descriptions for top_k and rerank. The description adds limited value: 'cursor pagination' clarifies the cursor parameter, and 'ranked' implies reranking. However, it does not explain query semantics, collection_ids filtering, or how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs hybrid search using dense, sparse, and BM25 methods, and returns ranked chunks with cursor pagination. This distinguishes it from siblings like ask_question (Q&A) and search_tools (tool lookup) by both method and result type.
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 provided on when to use this tool versus alternatives. It does not mention scenarios where ask_question or other search variants would be preferred, nor does it state exclusions or prerequisites.
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?
With no annotations, the description carries the full burden. It hints that content is optional ('Optionally include full content'), but does not disclose response format, error handling, permissions, or what happens when content is omitted. This is minimal transparency 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?
Two short, front-loaded sentences. Every word earns its place: the action, the resource identifier, and the optional flag. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but there is no output schema and no annotations. The description does not explain what is returned when content is excluded, or any pagination or formatting details. It is adequate for a basic get-by-ID, but not fully complete given the lack of structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'include_content' toggles full content inclusion, and document_id is self-explanatory from 'by ID'. This adds meaning beyond the schema, though it does not detail value formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('document by ID'). It also mentions optional content inclusion, distinguishing it from list-oriented siblings like list_documents. However, it does not explicitly contrast with search or list tools, so it misses the top mark for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this when you have a document ID. There is no explicit guidance about when not to use it or when to prefer alternatives like search or list_documents. For a simple fetch-by-ID tool, the implied context is adequate but not clearly stated.
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 burden. It discloses cursor pagination, which is useful behavioral information, but lacks details on permissions, return structure, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, both informative. The purpose is front-loaded, and every word earns its place.
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?
There is no output schema or annotations. The description only provides the bare minimum, leaving an agent without knowledge of what a collection looks like, the exact pagination behavior, or the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'Cursor pagination' as a hint but does not explain the limit or cursor parameters, their formats, or how they relate to pagination.
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 'List' and resource 'collections', with scope 'all', clearly distinguishing it from sibling tools like list_documents and list_snapshots.
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 provided on when to use this tool versus alternatives such as search or list_documents. The description simply states the action without context or exclusions.
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 that the tool returns added/deleted/changed counts, which is a useful behavioral detail. However, it does not mention read-only nature, permission requirements, performance considerations, or how edge cases (e.g., invalid snapshot IDs) are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with only 12 words. It is front-loaded and contains no filler or redundancy. Every word earns its place, making it an appropriately concise summary.
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 4 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the context for using snapshots (e.g., that they belong to a specific table/namespace), nor does it describe the return structure beyond 'counts'. The tool requires more context to be used correctly, especially with no schema descriptions to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 references 'two snapshots', which maps to from_snapshot_id and to_snapshot_id, but gives no information about table_name or namespace, nor does it clarify which parameters are required or optional. The description adds minimal value beyond the parameter names.
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 ('Compare') and resource ('two snapshots'), and clearly states the output ('added/deleted/changed counts'). This differentiates it from sibling tools like time_travel_query (query a single snapshot) and list_snapshots (list available snapshots).
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 provided on when to use this tool versus alternatives such as time_travel_query. The description implies a diffing use case but does not state explicit prerequisites, exclusions, or scenarios where another tool would be more appropriate.
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 states the tool returns tool info at a specified detail level, which is the core behavior, but does not disclose other traits like auth, rate limits, or handling of empty results. This is adequate but not thorough.
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 short sentences, front-loaded with the action verb, and contains no redundant content. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple three-parameter structure with no output schema or annotations. The description covers the primary purpose, search dimensions, and return detail behavior. It doesn't state defaults or sorting, but for a tool-lookup utility, this is reasonably 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 description clarifies that the query parameter searches by name/tag/description and that detail controls returned information, adding meaning beyond the schema. It also gives context for the undocumented 'tags' parameter by mentioning 'tag' as a search dimension. Schema coverage is 67%, so the description supplements gaps.
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 'Find' and identifies the resource 'available tools' with search dimensions (name, tag, description). It also specifies the return detail level, distinguishing it from sibling tools like 'search' or document retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case—discovering available tools—but does not explicitly state when to use it versus sibling tools like 'search' or 'get_document'. There are no exclusion criteria or alternative recommendations, so it provides clear context without exclusions.
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:

[![mcp-server MCP server](https://glama.ai/mcp/servers/lakehouse-42/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/lakehouse-42/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/lakehouse-42/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/lakehouse-42/mcp-server)

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/lakehouse-42/mcp-server'

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