Combined MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap. The vectorstore tools (build, get_status, query) handle knowledge base operations, while the Redshift tools (list_schemas, list_tables, describe_table, run_query) handle database operations. The separation between these two domains is unambiguous.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern. The verbs are descriptive (build, describe, get, list, query, run) and the nouns clearly indicate the target resource (vectorstore, table, schemas, tables, query). There are no deviations in naming conventions.
Tool Count4/5
With 7 tools, the count is reasonable for a combined server covering two domains. However, the vectorstore side feels slightly thin with only three tools (build, status, query), lacking operations like update or delete. The Redshift side is well-covered with four tools.
Completeness4/5
For the Redshift domain, the toolset provides comprehensive coverage (list schemas/tables, describe table, run query). For the vectorstore domain, core operations exist (build, query, status), but there are minor gaps such as updating or deleting documents from the knowledge base, which agents might need to work around.
Average 3.6/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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 mentions authentication parameters ('db_user', 'db_group') but doesn't explain what permissions are needed, whether this is a read-only operation, potential rate limits, or what the output looks like. For a tool with authentication requirements and no annotations, this is a significant gap 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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a concise 'Args' section listing parameters with brief explanations. Every sentence earns its place without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, authentication needs) and the presence of an output schema (which handles return values), the description is partially complete. It covers the purpose and parameters but lacks behavioral context like permissions or usage guidelines. With no annotations, it should do more to compensate, but the output schema reduces the burden slightly.
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 adds meaning by explaining that 'schema' is the 'Schema name to list tables from', 'db_user' is for 'Database user for authentication', and 'db_group' is 'Optional database group for permissions'. This clarifies the purpose of each parameter beyond their titles in the schema, but it doesn't provide format details or constraints, keeping it at a baseline level.
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's purpose: 'List all tables in a Redshift schema.' It specifies the verb ('List') and resource ('tables in a Redshift schema'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_schemas' or 'describe_table', which would require 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_schemas' (for listing schemas instead of tables) or 'describe_table' (for detailed table information), nor does it specify prerequisites or exclusions. Usage is implied by the purpose but not explicitly stated.
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 carries the full burden of behavioral disclosure. It implies a read-only operation by using 'List', but doesn't specify permissions needed, rate limits, pagination behavior, or what 'all schemas' entails (e.g., system vs. user schemas). This leaves significant gaps for a tool with authentication parameters.
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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value without redundancy, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, authentication required) and the presence of an output schema (which handles return values), the description covers the basic purpose and parameters adequately. However, it lacks behavioral details like permissions or scope, which are important for a database listing tool with no annotations.
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 adds meaningful context for both parameters: 'db_user' is explained as 'Database user for authentication' and 'db_group' as 'Optional database group for permissions'. With 0% schema description coverage, this compensates well by clarifying the purpose of each parameter beyond their names.
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 verb 'List' and resource 'all schemas in the Redshift database', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_tables' or 'describe_table', which would require 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?
The description provides no guidance on when to use this tool versus alternatives like 'list_tables' or 'describe_table'. It mentions authentication parameters but doesn't explain usage context or prerequisites beyond that.
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. While it mentions authentication via 'db_user' and permissions via 'db_group', it doesn't describe what 'detailed information' includes beyond columns and data types, whether this is a read-only operation, potential rate limits, or error conditions. The description is minimal and lacks crucial behavioral context for a tool with authentication parameters.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The Args section is structured but could be more integrated; however, every sentence adds value (e.g., clarifying parameter roles). Minor room for improvement in flow, but overall efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely covers return values), the description's minimalism is somewhat acceptable. However, for a tool with 4 parameters (including authentication) and no annotations, it should provide more behavioral context (e.g., read-only nature, error handling). The description is adequate but has clear gaps in usage guidelines and transparency.
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. It adds meaningful context for all parameters: 'schema' and 'table' are clearly identified as names, 'db_user' is explained as 'for authentication', and 'db_group' as 'Optional database group for permissions'. This goes beyond the schema's basic titles, providing purpose and usage hints for each parameter.
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 specific action ('Get detailed information') and resource ('about a Redshift table including columns and data types'), distinguishing it from sibling tools like list_tables (which likely lists names only) or run_query (which executes queries). The verb+resource combination is precise 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 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. It doesn't mention when this tool is appropriate (e.g., for metadata inspection vs. data retrieval) or differentiate it from siblings like list_tables or run_query. No explicit when/when-not statements or alternative tool references are included.
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 provided, the description carries full burden. It discloses the return content (build status, document count, cache statistics) which is valuable behavioral information. However, it doesn't mention performance characteristics, error conditions, rate limits, or authentication requirements that would be helpful for a status-checking 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 perfectly concise with two sentences that each earn their place. The first sentence states the purpose, the second describes return values. No wasted words, well-structured, and front-loaded with the core functionality.
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 tool has an output schema (which handles return value documentation), no parameters, and no annotations, the description provides adequate context. It clearly states what the tool does and what information it returns. For a simple status-checking tool with output schema support, this is reasonably complete, though could benefit from more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the empty parameter set. The description appropriately doesn't discuss parameters since none exist, earning a baseline 4 for parameter semantics when no parameters need explanation.
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's purpose as 'Get the current status of the knowledge base vector store' with specific verb ('Get') and resource ('knowledge base vector store'). It distinguishes from siblings like 'build_vectorstore' (creation) and 'query_vectorstore' (querying), but doesn't explicitly contrast with all siblings like 'describe_table' or 'list_tables'.
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. The description doesn't mention prerequisites, timing considerations, or contrast with similar tools like 'describe_table' or 'list_schemas' that might provide related metadata. Usage context is implied but not explicit.
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 provided, the description carries the full burden. It discloses key behavioral traits: the tool performs searches with caching for performance and supports three search types. However, it doesn't cover important aspects like rate limits, authentication needs, error conditions, or what 'cached for performance' entails operationally.
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 efficiently structured: purpose statement first, followed by key capabilities, behavioral note about caching, and clear parameter explanations. Every sentence adds value with zero waste, making it easy to parse quickly.
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 3 parameters with no schema descriptions, an output schema exists (so return values don't need explanation), and no annotations, the description provides solid coverage of purpose, parameters, and basic behavior. It could be more complete by addressing error cases or search result format, but covers the essentials well for a search 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?
With 0% schema description coverage, the description compensates well by explaining all three parameters: 'query' as search text, 'top_k' as maximum results with default, and 'search_type' as semantic/keyword/hybrid with default. It adds meaningful context beyond the bare schema, though could elaborate on parameter interactions.
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's purpose: 'Search the knowledge base vector store' with specific search methods (semantic, keyword, hybrid). It distinguishes itself from siblings like 'build_vectorstore' (creation) and 'run_query' (likely SQL queries), but doesn't explicitly contrast with other search-related tools if they exist.
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 through search method options (semantic, keyword, hybrid) and mentions caching for performance, but doesn't explicitly state when to use this tool versus alternatives like 'run_query' or provide clear exclusions. The guidance is functional but lacks explicit comparative context.
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 provided, the description carries full burden. It discloses key behavioral traits: it's a complex multi-step process involving downloading, processing, embedding generation, and storage. However, it doesn't mention potential side effects (e.g., overwriting existing data), performance characteristics (time/rate limits), authentication requirements, or error handling - significant gaps for a tool with no annotation coverage.
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 efficiently structured in two sentences: the first states the core purpose, the second elaborates the multi-step process. Every phrase adds value - 'from S3 markdown files,' 'configured S3 location,' and the specific technologies used (AWS Bedrock Titan, PostgreSQL) provide essential context 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?
Given this is a complex data processing tool with no annotations but with an output schema, the description provides good coverage of the operation's purpose and steps. It explains the source (S3 markdown), processing (chunking), embedding generation (AWS Bedrock Titan), and storage (PostgreSQL). The output schema will handle return values, so the description appropriately focuses on the transformation process rather than output 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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters, instead focusing on what the tool does. A baseline of 4 is appropriate for zero-parameter tools where the description doesn't need to compensate for schema 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 clearly states the specific action ('build or rebuild') and target resource ('knowledge base vector store'), with detailed explanation of the multi-step process. It distinguishes this tool from siblings like 'get_vectorstore_status' (monitoring) and 'query_vectorstore' (querying) by emphasizing creation/regeneration from source files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through phrases like 'from S3 markdown files' and 'configured S3 location,' suggesting this is for initial setup or refresh operations. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among siblings, though the distinction from query/monitoring tools is clear from their names.
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 full burden and does well by disclosing critical behavioral traits: the 100-row limit for direct returns, S3 storage for larger results, and authentication requirements via get_cluster_credentials. However, it doesn't mention rate limits, timeout behavior, or error handling for malformed queries.
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 efficiently structured with a clear purpose statement followed by important behavioral information, then parameter explanations. Every sentence adds value, and the Args section is appropriately formatted 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?
Given this is a database query execution tool with no annotations but with an output schema, the description provides good coverage of purpose, behavior, and parameters. However, it could better address error scenarios, performance characteristics, and how to retrieve full results from S3 when applicable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all three parameters: sql (the query to execute), db_user (for authentication), and db_group (optional permissions). It adds meaningful context about authentication via get_cluster_credentials that isn't in 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 clearly states the specific action ('Execute a SQL query') and target resource ('on Redshift'), distinguishing it from sibling tools like query_vectorstore or describe_table. It provides precise verb+resource information that helps the agent understand this is a database query execution tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for SQL query execution on Redshift, but doesn't explicitly state when to use this tool versus alternatives like query_vectorstore or describe_table. There's no guidance on prerequisites, error conditions, or specific scenarios where this tool is preferred over siblings.
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_servers MCP server](https://glama.ai/mcp/servers/manish6007/mcp_servers/badges/card.svg)](https://glama.ai/mcp/servers/manish6007/mcp_servers)

Score Badge

Copy to your README.md:

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

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/manish6007/mcp_servers'

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