Skip to main content
Glama
mohsinmshabbir

datasaudi-mcp

by mohsinmshabbir
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Server Quality Checklist

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

  • Latest release: v0.1.0

  • Disambiguation5/5

    Each tool has a clearly distinct purpose: describe_cube for metadata of a specific cube, list_cubes for searching the catalog, and query_cube for fetching data. There is no overlap or ambiguity in their functions.

    Naming Consistency5/5

    All tool names follow a consistent verb_noun pattern in snake_case: describe_cube, list_cubes, query_cube. This is perfectly regular and predictable.

    Tool Count4/5

    Three tools is appropriate for a focused data catalog server covering discovery, schema exploration, and data retrieval. While minimal, each tool earns its place and the set feels complete.

    Completeness5/5

    The tool set fully covers the main workflows: listing cubes, describing their structure, and querying with drilldowns and measures. Pagination and filtering are well addressed through parameters, leaving no obvious gaps.

  • Average 4.5/5 across 3 of 3 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 18 commits in the last 12 weeks
    • Last stable release on
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI is passing

  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • 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

  • Behavior3/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, so the description carries full burden. It discloses that locale only affects member captions (not names), and that unknown cubes return a 'did you mean' error. However, it does not explicitly state read-only behavior or any potential side effects, which is a minor gap.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is concise (three sentences) with key information front-loaded. No unnecessary words, every sentence adds value.

    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 three parameters, no annotations, and an output schema (not detailed), the description covers the core functionality: cube structure, optional member listing, and locale handling. It also mentions error messaging. It is nearly complete, though it could mention the output format or link to the output schema.

    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 explains that cube is required, level lists members when provided, and locale controls caption language with a default of 'en'. This adds significant meaning beyond the schema, though it could clarify the type of members (e.g., all members or just top-level).

    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 'Introspect one cube: its drillable level names and measures.' This is a specific verb (introspect) and resource (cube), and it distinguishes from siblings list_cubes and query_cube by focusing on a single cube's structure.

    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 explains when to pass optional parameters (level to list members, locale for language), and mentions error behavior for unknown cubes. It could be more explicit about not using for querying data, but the distinction from sibling tools is clear enough.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior5/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries full burden. It discloses the envelope return format, total_matches vs complete flag, scope specifics, locale effects, retry with underscores, and empty query preview. This is richly transparent.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is front-loaded with the main purpose and then detailed. Though somewhat lengthy, every sentence contributes essential information. Minor room for tightening, but overall 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?

    Given the tool's complexity (4 parameters, output schema exists), the description covers return envelope, pagination, scope variants, locale, retry logic, and empty query behavior. It is highly complete and leaves no critical gaps.

    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 no descriptions (0% coverage), but the description adds meaning for all four parameters—query, scope, locale, offset—by explaining their values and behavior in context. It does not list each parameter separately but effectively conveys semantics.

    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 searches the DataSaudi catalog of 277 statistical cubes, establishing a specific verb and resource. It distinguishes itself from sibling tools (describe_cube, query_cube) by focusing on listing/searching.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description provides clear context on when to use the tool, including scope options (catalog, measures, levels), locale behavior, pagination via offset, and retry logic. While it does not explicitly exclude alternative tools, the use cases are well-defined.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior5/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations, description fully discloses behaviors: cut on nonexistent member returns 0 rows, locale only affects captions, limit hard-capped at 5000, silent reduction, pagination via offset, error on large result, and warning against averaging across pages. Thorough and honest.

    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?

    Well-structured with paragraphs, bolding, and clear warnings. Every sentence adds value, though slightly lengthy. Could be more concise but remains effective and easy to parse.

    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 all 7 parameters, pagination, error cases, integration with describe_cube, and output schema existence. Complete for an AI agent to use correctly without further clarification.

    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?

    Since schema description coverage is 0%, description compensates by providing detailed semantics for all parameters: cut format, locale values, limit/offset pagination, and measures/drilldowns as arrays. Adds meaning beyond 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?

    Clearly states the tool queries a cube with drilldowns and measures, returning paginated results. Distinguishes from siblings (describe_cube, list_cubes) implicitly by focusing on data retrieval.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Provides explicit guidance on when to use pagination, cut, locale, limit, and offset. Warns against raising limit beyond 5000 and explains paging vs narrowing. Could be more explicit about when to use this tool versus describe_cube, but context is clear.

    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

datasaudi-mcp MCP server

Copy to your README.md:

Score Badge

datasaudi-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/mohsinmshabbir/datasaudi-mcp'

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