StarTree MCP Server for Apache Pinot

Official

by startreedata

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Each tool targets a specific resource (schema, table, segment, query, connection) and action (create, get, list, update, test, read), making it easy for an agent to select the correct tool. For example, 'get-schema' and 'update-schema' are clearly differentiated by their actions on the same resource.
Naming Consistency5/5
Tool names follow a highly consistent verb-noun pattern throughout, using kebab-case (e.g., create-schema, get-table-config, list-tables). This predictable naming convention enhances readability and makes the tool set easy to navigate. All tools adhere to this style without any deviations or mixed conventions.
Tool Count5/5
With 14 tools, the count is well-scoped for managing Apache Pinot databases, covering essential operations like schema and table configuration, querying, segment management, and diagnostics. Each tool earns its place by addressing a specific need in the domain, avoiding bloat or thin coverage.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for Apache Pinot management, including create, read, update, and list operations for schemas, tables, and segments, plus query execution and connection testing. There are no obvious gaps or dead ends, enabling agents to handle full workflows effectively.
Average 2.5/5 across 14 of 14 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 3 community issues answered or closed in the last 6 months
- 25 commits in the last 12 weeks
- Last stable release on August 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
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

Behavior1/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. 'Create table configuration' implies a write operation but fails to describe any behavioral traits such as permissions required, whether the creation is idempotent, error handling, or side effects. This leaves critical operational context unspecified for a mutation 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 extremely concise with a single three-word phrase, 'Create table configuration', which is front-loaded and wastes no words. While it lacks detail, it efficiently communicates the core action without unnecessary elaboration, earning full marks for brevity and structure.
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's complexity as a mutation operation with two parameters, 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It does not compensate for the lack of structured data, failing to explain behavior, parameters, or outcomes, making it inadequate for effective tool use.
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%, meaning parameters are undocumented in the schema. The description adds no information about the two parameters ('tableConfigJson' and 'validationTypesToSkip'), their purposes, formats, or examples. For a tool with two parameters and no schema documentation, this represents a significant gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create table configuration' is a tautology that restates the tool name with minimal elaboration. It specifies the verb 'Create' and resource 'table configuration', but lacks specificity about what a table configuration entails or how it differs from sibling tools like 'create-schema' or 'update-table-config'. This provides only basic purpose without meaningful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, appropriate contexts, or exclusions, nor does it reference sibling tools like 'create-schema' or 'update-table-config' for comparison. Without any usage instructions, the agent lacks direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. The description only states 'Get table configuration', offering no information about whether this is a read-only operation, what permissions are required, how errors are handled, or what the output format might be. This is inadequate for a tool with parameters and no output schema.
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 with just three words, making it front-loaded and free of unnecessary details. However, this conciseness comes at the cost of under-specification, but based solely on structure and brevity, it earns full marks for being succinct.
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 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what table configuration includes, how to use the parameters, what the tool returns, or how it differs from sibling tools. This leaves significant gaps for an AI agent to understand and invoke the tool correctly.
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 schema description coverage is 0%, meaning neither parameter ('tableName' and 'tableType') is documented in the schema. The description adds no information about these parameters—it doesn't explain what 'tableName' refers to, what 'tableType' might be, or how they affect the configuration retrieval. This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get table configuration' is essentially a tautology that restates the tool name 'get-table-config' with minimal elaboration. It specifies the verb 'Get' and resource 'table configuration', but provides no additional detail about what table configuration entails or distinguishes it from sibling tools like 'table-details' or 'tableconfig-schema-details'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools related to tables and configurations (e.g., 'table-details', 'tableconfig-schema-details', 'list-tables'), there is no indication of when this specific tool is appropriate, what prerequisites exist, or what distinguishes it from other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 states 'update' implies a mutation but fails to describe permissions needed, whether changes are reversible, side effects, or response format. This is inadequate for a mutation tool with zero 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 extremely concise with a single phrase, 'Update table configuration', which is front-loaded and wastes no words. However, this conciseness comes at the cost of underspecification, but it earns full marks for 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?
Given the complexity of a mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It lacks essential details on behavior, parameters, usage, and output, making it insufficient for effective tool 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 description coverage is 0%, meaning all three parameters (tableConfigJson, tableName, validationTypesToSkip) are undocumented in the schema. The description adds no information about these parameters, their purposes, formats, or examples, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update table configuration' restates the tool name 'update-table-config' with minimal elaboration, making it tautological. It specifies the verb 'update' and resource 'table configuration' but lacks detail on what aspects of configuration are updated or how this differs from sibling tools like 'update-schema' or 'create-table-config'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'create-table-config' or 'update-schema'. The description offers no context, prerequisites, or exclusions, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Create a new schema' implies a write/mutation operation, but it doesn't describe permissions needed, whether it's idempotent, what happens on conflicts, or any side effects. For a tool with 3 parameters and no annotation coverage, 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 extremely concise with a single sentence ('Create a new schema'), which is front-loaded and wastes no words. While it's under-specified, it's not verbose or poorly structured—it efficiently states the core action without unnecessary elaboration.
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 complexity (a mutation tool with 3 parameters, no annotations, and no output schema), the description is completely inadequate. It doesn't explain what the tool returns, how to handle errors, or the meaning of parameters. For a tool that likely creates database schemas with configuration options, this lacks essential context for effective use.
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%, meaning none of the 3 parameters (force, override, schemaJson) are documented in the schema. The description adds no information about these parameters—it doesn't explain what schemaJson should contain, when to use force or override, or their interactions. With low coverage and no compensation in the description, this fails to provide parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new schema' is a tautology that merely restates the tool name without adding specificity. It doesn't explain what kind of schema is being created, what resource it affects, or how it differs from sibling tools like 'update-schema' or 'get-schema'. While it uses a clear verb ('Create'), it lacks the resource and scope details needed for full clarity.
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. With siblings like 'update-schema' and 'get-schema', it doesn't specify if this is for initial creation only, what prerequisites might exist, or when to choose it over other tools. There's no mention of context, exclusions, or alternatives, leaving usage ambiguous.
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 states 'Get' which implies a read-only operation, but it doesn't clarify if this requires specific permissions, what the return format is (e.g., structured data, error handling), or any rate limits. The description is minimal and lacks essential behavioral context for safe and effective use.
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, efficient sentence with no wasted words, making it easy to parse. However, it's front-loaded but under-specified—while concise, it lacks the necessary detail to be fully helpful, balancing brevity with insufficient information.
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 complexity of a tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'index/column details' include, how results are structured, or any dependencies, making it inadequate for the agent to understand the tool's full context and usage.
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?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'for a segment', which hints at the 'segmentName' parameter, but doesn't explain what 'segment' means or how it relates to 'tableName'. No additional semantics are provided for the two required parameters, leaving their purpose and usage unclear beyond the schema's basic types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get index/column details for a segment' clearly states the action (get) and resource (index/column details), but it's vague about what 'details' entail and doesn't differentiate from siblings like 'segment-metadata-details' or 'table-details'. It specifies the scope ('for a segment') but lacks precision about the output format or depth of information.
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 on when to use this tool versus alternatives like 'segment-metadata-details' or 'table-details' is provided. The description implies usage for retrieving index/column information related to a segment, but it doesn't specify prerequisites, exclusions, or comparative contexts with sibling tools, leaving the agent to infer usage based on tool names 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get') without explaining what 'Get' entails—such as whether it's a read-only operation, if it requires permissions, what format the output is in, or any rate limits. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, making it front-loaded and efficient. However, this brevity borders on under-specification, as it lacks necessary details for a tool with behavioral and parameter gaps, slightly reducing its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with one parameter), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't address behavioral traits, parameter meaning, or output details, making it inadequate for the agent to use the tool correctly without additional context.
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%, meaning the input schema provides no descriptions for the 'tableName' parameter. The description adds no semantic information about this parameter, such as what constitutes a valid table name, examples, or constraints. With one undocumented parameter, the description fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get table config and schema' clearly states the verb 'Get' and the resources 'table config and schema', providing a basic understanding of what the tool does. However, it doesn't differentiate this tool from its siblings 'get-schema' and 'get-table-config', which appear to perform similar functions, making the purpose somewhat vague in context.
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 'get-schema' or 'get-table-config'. It lacks any context about prerequisites, exclusions, or comparisons with sibling tools, leaving the agent with no usage direction beyond the basic purpose.
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 states the action ('Update') but doesn't reveal critical traits: whether this is a safe or destructive operation, permission requirements, side effects (e.g., impact on existing data), rate limits, or error handling. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it immediately understandable at a basic level. Every word earns its place, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation operation with 4 parameters), lack of annotations, 0% schema coverage, and no output schema, the description is severely incomplete. It doesn't address behavioral risks, parameter meanings, return values, or differentiation from siblings. For a schema-update tool in this context, the description provides inadequate guidance.
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 for undocumented parameters. It mentions no parameters at all, failing to explain the meaning of 'schemaName', 'schemaJson', 'force', or 'reload'. The description adds zero value beyond what the bare schema provides, leaving all four parameters semantically opaque to the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing schema' clearly states the verb ('Update') and resource ('existing schema'), making the basic purpose understandable. However, it doesn't distinguish this tool from its sibling 'update-table-config' or other schema-related tools, leaving ambiguity about what specifically gets updated. The description is functional but lacks specificity about scope or differentiation.
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 'create-schema' or 'update-table-config'. It doesn't mention prerequisites (e.g., schema must exist), exclusions, or contextual triggers. The agent must infer usage from the tool name alone, which is insufficient for informed selection among siblings.
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 full burden for behavioral disclosure. 'Fetch' implies a read operation, but the description doesn't specify whether this requires authentication, what happens if the schema doesn't exist, rate limits, or what format the returned data takes. This leaves significant behavioral 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 extremely concise at just three words, front-loading the essential information with zero wasted language. Every word earns its place in communicating the core function.
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 no annotations, no output schema, and minimal parameter documentation, the description is insufficiently complete. It doesn't address what the tool returns, error conditions, authentication requirements, or how it differs from similar schema-related tools in the sibling list. The context demands more comprehensive guidance.
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?
With 0% schema description coverage and a single required parameter 'schemaName', the description adds minimal value beyond the schema. It mentions 'by name' which hints at the parameter's purpose, but doesn't explain what constitutes a valid schema name, format expectations, or whether it's case-sensitive. The description doesn't adequately compensate for the lack of schema 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 action ('fetch') and resource ('schema by name'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'tableconfig-schema-details' or 'update-schema' that also involve schemas, so it doesn't reach the highest clarity level.
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. With siblings like 'tableconfig-schema-details' and 'update-schema' that also handle schemas, there's no indication of when this specific fetch operation is appropriate versus other schema-related operations.
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 full burden for behavioral disclosure. While 'Execute a SELECT query' implies a read-only operation, it doesn't specify permissions needed, query limitations (e.g., timeout, result size), error handling, or what the response looks like. This leaves significant gaps for a database query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded with the core action.
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 no annotations, no output schema, and a database query tool that could have complex behaviors (e.g., SQL syntax, result format, error cases), the description is incomplete. It doesn't address what the tool returns, how to handle queries, or any constraints, leaving the agent with insufficient 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 100%, with the single parameter 'query' documented as 'SELECT SQL query to execute' in the schema. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline for high schema coverage.
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 ('Execute') and target ('SELECT query on the Pinot database'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling query execution tools (though none are listed among siblings), keeping it from a perfect score.
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. With siblings like 'list-tables' or 'table-details' that might provide related data, there's no indication of when a SELECT query is preferred over those structured retrieval methods.
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 states the action ('List segments') but does not describe traits such as whether this is a read-only operation, if it requires specific permissions, what the output format looks like (e.g., list of segment names or objects), or any rate limits. The description is minimal and lacks essential behavioral context 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 a single, clear sentence with zero wasted words. It is appropriately sized for a simple list operation and front-loaded with the core action. Every part of the sentence earns its place by directly stating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is incomplete. It lacks information on behavioral traits (e.g., read-only nature, output format), usage context, and does not leverage the absence of annotations to provide necessary details. For a tool with no structured data beyond the input schema, the description should do more to ensure the agent can use it correctly.
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 100%, with the parameter 'tableName' fully documented in the schema as 'Table name'. The description does not add any meaning beyond this, such as explaining what constitutes a valid table name or providing examples. With high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
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 ('segments for a table'), making the purpose understandable. It distinguishes from siblings like 'list-tables' (which lists tables) or 'segment-metadata-details' (which provides detailed metadata), but could be more specific about what 'segments' are in this context. No tautology or misleading elements are present.
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 does not mention prerequisites (e.g., needing an existing table), exclusions, or comparisons to siblings like 'segment-metadata-details' (which might offer more detailed segment information). Usage is implied by the action but lacks explicit context.
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 states 'Get metadata for segments of a table', which implies a read-only operation, but does not specify permissions, rate limits, error handling, or what 'metadata' entails (e.g., format, scope). This is inadequate 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 a single, clear sentence with no wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
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 lack of annotations and output schema, the description is incomplete. It does not explain what 'metadata' includes, how segments are defined, or the return format. For a tool that likely returns structured data about table segments, this leaves significant gaps in understanding its behavior and output.
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?
The input schema has one parameter 'tableName' with 0% description coverage, and the description does not add any details about this parameter (e.g., format, examples, constraints). Since there is only one parameter, the baseline is 4, but the description fails to compensate for the lack of schema documentation, so it is scored lower as it provides no semantic value beyond the schema.
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 'Get' and the resource 'metadata for segments of a table', which is specific and understandable. However, it does not explicitly differentiate from sibling tools like 'segment-list' or 'table-details', which might have overlapping or related functionality, so it falls short of a perfect score.
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. With siblings such as 'segment-list' and 'table-details', there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage from the 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't specify what 'size details' includes (e.g., row count, storage size, partitions), whether there are rate limits, authentication requirements, or error conditions. This leaves significant gaps in understanding the tool's behavior.
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 at just three words, with zero wasted language. It's front-loaded with the core purpose and doesn't include any unnecessary elaboration, making it efficient for quick understanding.
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 lack of annotations and output schema, the description is incomplete for a tool that presumably returns detailed table information. It doesn't explain what 'size details' encompasses, the format of the response, or any behavioral nuances, leaving the agent with insufficient context to use the tool effectively.
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 100%, with the single parameter 'tableName' clearly documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for adequate but unremarkable coverage.
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 'Get' and the resource 'table size details', making the purpose understandable. However, it doesn't distinguish this tool from potential sibling tools like 'get-table-config' or 'segment-metadata-details' that might also retrieve table-related information, preventing a perfect score.
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. With multiple sibling tools like 'get-table-config', 'segment-metadata-details', and 'list-tables', there's no indication of what makes 'table-details' unique or when it should be preferred over other table-related tools.
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. It states the action ('List all tables') but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, pagination, or what the output format looks like. This is a significant gap for a tool with zero 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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'List all tables' entails—such as the return format, any limitations, or how it interacts with the Pinot system. For a tool with no structured data to rely on, this leaves critical gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but that's acceptable here since there are no parameters to describe, aligning with the baseline for zero parameters.
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 ('tables in Pinot'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'table-details' or 'tableconfig-schema-details', which might also involve table information, so it doesn't fully distinguish its scope.
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. With siblings like 'table-details' (likely for specific table info) and 'tableconfig-schema-details' (likely for configuration), there's no indication of context or exclusions, leaving the agent to infer usage.
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 states the tool tests a connection and returns diagnostics, but doesn't elaborate on what 'diagnostics' includes (e.g., success/failure status, error details, performance metrics), whether it's a read-only operation, if it has side effects (e.g., logging or caching), or any rate limits. This leaves significant gaps in understanding the tool's behavior.
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, efficient sentence that front-loads the core action ('Test Pinot connection') and outcome ('return diagnostics'). There's no wasted wording, and it's appropriately sized for a simple, parameterless tool, making it easy for an agent to parse quickly.
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 low complexity (0 parameters, no annotations, no output schema), the description is minimally adequate. It states what the tool does, but lacks details on diagnostics content or behavioral traits. For a connection-testing tool, more context on output format or error handling would be helpful, though the simplicity keeps it from being severely incomplete.
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, and the schema description coverage is 100%, so there's no need for parameter details in the description. The description doesn't add parameter semantics, but that's appropriate here. A baseline of 4 is applied since no parameters exist, and the description doesn't mislead about inputs.
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 with a specific verb ('Test') and resource ('Pinot connection'), and indicates it returns diagnostics. However, it doesn't explicitly differentiate this from sibling tools like 'read-query' or 'table-details' that might also involve connection testing indirectly, so it doesn't reach the highest score.
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 prerequisites (e.g., whether a connection must be established first), typical use cases (e.g., troubleshooting or setup verification), or how it differs from other tools that might test connectivity as a side effect. This lack of context leaves the agent with minimal usage direction.
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-pinot MCP server](https://glama.ai/mcp/servers/startreedata/mcp-pinot/badges/card.svg)](https://glama.ai/mcp/servers/startreedata/mcp-pinot)

Score Badge

Copy to your README.md:

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

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/startreedata/mcp-pinot'

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