schemabrain

by Arun-kc

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.6.1
Disambiguation5/5
Each tool has a clearly distinct purpose: describing at column/table/entity level, finding semantically, listing, getting metrics, resolving joins. No overlapping functionality; differences are explicitly noted in descriptions.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., describe_column, list_metrics, suggest_joins). No mixing of conventions like camelCase or different verb styles.
Tool Count5/5
12 tools is well-scoped for a schema analysis server, covering discovery, description, joining, and metric computation. Not excessively many nor too few.
Completeness4/5
The tool surface covers the core domain of schema exploration and metric queries comprehensively. Minor missing features like listing all tables at once, but overall no critical gaps for its purpose.
Average 4.9/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 229 commits in the last 12 weeks
- Last stable release on June 13, 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.
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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds specific behavioral details: returns entity's bound table, identity column, description, and full column list with PII sensitivity. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary use case. Every sentence adds value, covering when to use, what it returns, and how to compose with other tools. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, strong annotations, and an output schema, the description is complete. It explains the return structure, prerequisites, and integration with sibling tools, leaving no gaps for an AI agent to misinterpret.
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 100% and the input schema already provides a thorough parameter description including format constraints (no dots, no schema qualifier) and a prerequisite (call list_entities first). The tool description repeats these points without adding new parameter-specific semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to describe a specific entity when the user names it. It specifies what the tool returns (bound table, identity column, description, full column list with PII sensitivity) and distinguishes it from sibling tools like list_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use this tool (user names a specific entity) versus alternatives (list_entities when entities are unknown). Also provides common compositions with describe_table and describe_column, showing how to chain tools effectively.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, covering safety and idempotency. The description adds valuable behavioral context by listing exactly what is returned (columns with types, nullability, PK flags, LLM descriptions, outgoing FKs), leveraging the annotations effectively.
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, well-structured paragraph that front-loads the purpose and then provides usage guidance. Every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not needed to explain return values), the description covers all necessary aspects: when to use, what it returns, and how to chain with other tools. It is complete for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear parameter description. The tool description adds extra guidance by advising to call `find_relevant_tables` first if the schema is unknown, which goes beyond the schema alone.
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 specifies the tool's exact purpose: describing a table by qualified name, returning detailed schema information. It clearly distinguishes from sibling tools like `find_relevant_tables` (for semantic description) and `describe_column` (drilling into columns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (user provides qualified name) and when to use `find_relevant_tables` instead (user describes table semantically). Provides common compositions like chaining to `describe_column` or `suggest_joins`, offering clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent, open-world. Description adds behavioral context: returns 'every confirmed entity' with specific fields. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adds value: usage trigger, return description, differentiation, composition examples. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete given zero parameters, full annotations, and presence of output schema. Covers purpose, usage, return structure, and composition.
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?
No parameters in schema; baseline for 0 params is 4. Description correctly omits parameter details as none exist.
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?
Clearly states the tool returns every confirmed entity with bound table, identity column, and provenance. Differentiates from sibling `describe_entity` by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user asks what entities are defined) and when not to (use `describe_entity` if entity name known). Provides common compositions like chaining to `describe_entity` or `find_relevant_tables`.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that the tool returns 'each confirmed join with the entity pair it connects and provenance.' No contradictions. Could mention scope (all joins across workspace) but not necessary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste. First sentence states purpose and trigger, second and third provide clear alternatives. Front-loaded structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, comprehensive annotations, and an output schema (not shown but exists). The description covers what it does, when to use, what it returns, and distinguishes from siblings. Complete for a list 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?
There are no parameters, and the schema coverage is 100%. Baseline for 0 parameters is 4. The description adds no parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('list'), resource ('canonical joins'), and scope. It clearly distinguishes from sibling tools by explicitly naming `resolve_join` and `suggest_joins` with their appropriate use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when the user asks what canonical joins are defined') and when to use alternatives (e.g., `resolve_join` for known pairs, `suggest_joins` for physical-table names only).
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds algorithmic details: ranking by cosine similarity, scoring as MAX across columns. Discloses what the tool does without contradicting annotations. Could mention any rate limits, but not essential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose and usage, then alternatives and compositions. No wasted words; each sentence earns its place. Highly concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, annotations are rich, and both parameters are fully described in schema and description, the description covers purpose, usage, algorithm, and compositions. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant meaning beyond parameter names/types: explains 'query' as natural-language and how searching works (embedding, cosine similarity), and 'limit' with usage guidance (3-5 for narrow, 10-20 for survey). This is exemplary.
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 it is used when the user describes a business object, returns ranked entities, and distinguishes from sibling 'find_relevant_tables'. It specifies verb ('find'), resource ('relevant entities'), and scope ('business terms').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when...' and 'Use find_relevant_tables instead when...' and lists common compositions (chain to describe_entity, resolve_join, get_metric). Provides clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety profile (readOnly, idempotent, non-destructive). The description adds valuable behavioral details: it returns data type, nullability, default, LLM description, and both outgoing and incoming foreign key directions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. First sentence states purpose and key output, second gives alternative, third provides composition pattern. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, full annotations, and an output schema (present, though not detailed here), the description covers the tool's purpose, output, and usage flow comprehensively. No missing information.
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 single parameter 'qualified_name' is well-described in the schema (100% coverage). The description adds extra guidance on the format (e.g. 'public.orders.user_id') and a prerequisite hint to call describe_table first if needed, exceeding baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('drill into') and resource ('one column'), and distinguishes it from the sibling 'describe_table' by specifying it works on a single column with a three-part qualified name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('when you need to drill into one column'), when to use the alternative ('Use describe_table instead when you want the whole table'), and provides a common composition pattern ('chain describe_table to describe_column').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey safety (readOnly, idempotent). Description adds critical behavioral details: returns cosine-ranked hits, shows matched column and its LLM description, and reveals the embedding model used. These details help the agent understand the return format and reasoning, beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with primary use case, no redundant information. Every sentence adds distinct value: purpose, differentiation, and composition advice. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema (not shown), the description explains key return elements (cosine scores, matched column, LLM description) and provides composition chains with sibling tools. Given the tool's moderate complexity and 11 siblings, the description fully equips the agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with good descriptions, achieving 100% coverage. The description adds valuable usage guidance for the limit parameter ('Use a small value (3-5)...'), enhancing the agent's ability to select appropriate values. This extra context raises the score above baseline 3.
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?
Clearly states the tool's purpose: 'Use this when the user describes tables semantically' with concrete examples ('the table with customer orders'). Directly distinguishes from sibling tool `describe_table`, making purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use ('semantic descriptions'), when to use an alternative ('Use describe_table instead when the user names a specific table'), and suggests multi-step compositions with `describe_table` and `suggest_joins`. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, destructive=False, idempotent, and openWorld. The description adds significant behavioral context: automatic multi-hop join chaining, the impact of `order_by` on determinism and the `missing_order_by_with_limit` flag, limit enforcement, error handling (e.g., `ambiguous_path`, `unknown_order_by_column`), and the `via` disambiguation mechanism. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but informative. It starts with the core purpose in the first sentence, then adds essential details about auto-joins, determinism, `order_by`, and error handling. Every sentence adds value, and there is no redundancy or fluff. The structure is logical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, output schema present, rich annotations), the description covers all necessary aspects: when to use, automated behavior, error conditions, and parameter guidance. The existence of an output schema reduces the need to describe return values. The description is complete for an AI agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining high-level usage patterns: e.g., how `order_by` enables deterministic ranking and that the compiler auto-appends a tie-breaking key, how `via` resolves ambiguity, and the effect of missing `order_by`. These contexts are not explicitly in the per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is for when you have a metric name and want ranked/sliced rows (top-N, most/highest/lowest). It distinguishes from the sibling `list_metrics` by noting that `list_metrics` is for when you don't know the metric name. The purpose is clear, specific, and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance (when you have a metric name and want ranked/sliced rows) and when-not-to-use (use `list_metrics` if you don't know the metric name). It also details behavior with and without `order_by`, error cases like `ambiguous_path`, and the `via` parameter for disambiguation, offering comprehensive contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), description discloses that the tool returns every declared metric with structure details, adding value for agent understanding of 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?
Three concise, front-loaded sentences that cover purpose, usage, and chaining without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 parameters and an output schema (assumed), description fully covers the tool's role, usage context, and output nature.
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?
No parameters exist, so baseline is 4. Description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns metrics for ranking/aggregation questions and specifies the output includes anchor entity, aggregation, and time-bucketing. It distinguishes from sibling 'get_metric' by clarifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly says when to use (ranking/top-N/aggregation questions) and when not to (use 'get_metric' if metric name is known). Also provides chaining advice to 'describe_entity'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior; the description adds context about returning status:empty when not populated, the data source (pg_stat_statements), and the prerequisite (run schemabrain mine-queries), going well beyond annotations.
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?
Every sentence adds value: purpose, return contents, empty status, alternative, and composition suggestion. No filler, well-front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what is returned, when empty, prerequisite, alternative, and composition. With an output schema present, no further detail needed on return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter, qualified_name, is thoroughly described in the schema with format, example, source, and prerequisite; no ambiguity remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides real example SQL for an indexed table, distinguishing it from siblings like describe_table by explicitly contrasting usage patterns with structural shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells when to use (need real example SQL) and when not (table has no recorded examples), provides a direct alternative (describe_table), and suggests a common composition pattern (chain with find_relevant_tables).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. Description adds direction-insensitivity and disambiguation behavior (null returns ambiguity refusal with names), providing valuable behavioral context beyond annotations.
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?
Four concise sentences covering purpose, usage context, and disambiguation behavior with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations (read only, idempotent) and output schema existence, description covers key behavioral aspects (direction, disambiguation, return type) completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline. Description adds meaning: order independence for entity_a/b, requirement for entities to exist, and detailed explanation of the name parameter's behavior when null.
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?
Description clearly states verb (resolve/gets join), resource (two entity names), and output (ready-to-paste JOIN clause with column mapping). Differentiates from siblings by naming alternatives (suggest_joins, list_entities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (have two entity names, need canonical join), when not to use (discover entities first, use suggest_joins for physical tables), and provides context like direction-insensitivity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior beyond annotations: returns shortest FK path, multi-hop paths, unreachable pairs, and performance notes on `max_hops`. No contradiction with annotations (all safe, idempotent).
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?
Concise, front-loaded with usage context, then details. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations, and schema, the description is complete. It covers input, output, behavior, and edge cases (unreachable pairs, depth limits).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context: qualified name requirement, one shortest path per unordered pair, unreachable pairs list, and semantics of `max_hops` including default and performance considerations.
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?
States the specific action: finding join paths between known tables using qualified names. Explicitly distinguishes from the sibling tool `find_relevant_tables`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use (when tables are known) and when not to (use `find_relevant_tables` instead). Also describes common composition with `find_relevant_tables`.
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:

[![schemabrain MCP server](https://glama.ai/mcp/servers/Arun-kc/schemabrain/badges/card.svg)](https://glama.ai/mcp/servers/Arun-kc/schemabrain)

Score Badge

Copy to your README.md:

[![schemabrain MCP server](https://glama.ai/mcp/servers/Arun-kc/schemabrain/badges/score.svg)](https://glama.ai/mcp/servers/Arun-kc/schemabrain)

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/Arun-kc/schemabrain'

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