MCP Sankhya Community Search Server

by delt4d

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.1.0
Disambiguation4/5
Most tools have clearly distinct purposes: read-only query, insert/update/delete, procedure call, DDL operations, and Sankhya service calls. The catch-all execute_unsafe_query overlaps by design but is explicitly labeled as the unrestricted fallback, so the boundaries are mostly clear.
Naming Consistency2/5
SQL tools consistently follow a verb_noun pattern (execute_query, insert_query, create_trigger), but the Sankhya tools reverse the order with a domain prefix (sankhya_call_service, sankhya_list_connections). This mixed convention creates confusion about whether the tool name starts with the action or the domain.
Tool Count4/5
12 tools is within the typical well-scoped range. The set covers both Oracle SQL operations and Sankhya service integration, though the presence of both specialized DDL tools and execute_unsafe_query introduces some redundancy.
Completeness3/5
The SQL tools cover insert, update, delete, query, procedure/trigger management, and unsafe fallback, but there is no schema discovery tool like list_tables or describe_table. The Sankhya integration is minimal (call service, list connections) and may not cover all necessary service operations.
Average 4.3/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
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the destructive/replacing nature is known. The description adds valuable context beyond annotations: 'Commits automatically (DDL)' and 'Only available on writable connections.' These are behavioral constraints not present in the annotations, and they do not contradict them.
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 three short sentences, front-loaded with the main purpose and immediately followed by essential constraints. There is zero fluff or repetition of schema/annotation details.
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?
For a simple 2-parameter tool with an output schema and destructiveHint annotation, the description covers the essential operating context: what it creates/replaces, the required SQL form, auto-commit behavior, and connection restrictions. It doesn't explain return values, but the output schema exists and the tool is straightforward, so this is reasonably complete.
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%, and the schema descriptions for both parameters ('Connection name from list_schemas. Must have readonly=false.' and 'Full CREATE OR REPLACE PROCEDURE/FUNCTION/PACKAGE [BODY] DDL statement.') are already detailed. The description adds a general rule ('must start with CREATE') but does not add much beyond the schema, so the baseline 3 is appropriate.
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 a specific verb ('Create or replace') and resource ('procedure, function, or package') and adds scope via 'full DDL statement'. It distinguishes from siblings like create_trigger and call_procedure by naming the exact object types, so the agent knows exactly what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context: the statement must start with CREATE and only works on writable connections, which implies when it can be used. However, it does not explicitly mention alternatives or when not to use it (e.g., versus execute_unsafe_query for DDL). This is clear context but no explicit exclusions or alternatives, so it earns a 3.
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?
The description adds behavioral context beyond the annotations by explaining the response structure (status with '1'=ok/'0'=erro and responseBody). It does not contradict the readOnlyHint=false annotation. It could include more side-effect warnings, but the annotation already signals possible writes and the openWorldHint gives additional context.
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 three short, front-loaded sentences with no filler. Each sentence provides distinct value: what the tool does, what the response looks like, and where to find connection details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a rich input schema, an output schema, and annotations, the description covers the essential behavioral aspects (invocation, response status, connection discovery). It is sufficiently complete for a generic REST service caller, though it could mention error handling or side-effect variability explicitly.
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 already provides 100% coverage of parameter descriptions, including examples for service_name and the request_body wrapper format. The tool description does not add further parameter semantics; it mainly reiterates the connection lookup already mentioned in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls a Sankhya service via REST API, using a specific verb ('Chama') and resource ('serviço Sankhya via API REST'). It also specifies the response format, which distinguishes it from sibling tools like execute_query or call_procedure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a useful pointer to sankhya_list_connections for discovering connections, which helps with a prerequisite. However, it does not explicitly state when to prefer this tool over alternatives like execute_query or call_procedure, nor does it provide exclusions or alternative 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?
Beyond the annotations (destructiveHint: true), the description discloses that it commits automatically (DDL) and is only available on writable connections, which are important behavioral traits. It does not contradict the 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 with three short sentences, each providing meaningful information without filler. It is well-structured and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are present, the description covers the core behavior and constraints (DDL, commit, writable connection) adequately. It does not need to detail return values or every edge case.
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 schema has 100% coverage for both parameters (connection and trigger_sql), so the description adds little extra meaning. It restates that the statement must start with CREATE, but this is already implied in the trigger_sql schema description.
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 'Create or replace a trigger using a full DDL statement' with a specific verb and resource, clearly distinguishing it from sibling tools like create_procedure and set_trigger_status. It also adds constraints like 'must start with CREATE' and 'Only available on writable connections'.
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 usage context by stating the tool only works on writable connections, commits automatically, and requires the statement to start with CREATE. However, it does not explicitly mention alternatives or when not to use this tool versus siblings like set_trigger_status.
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 openWorldHint=false. The description adds specific constraints: only SELECT and EXPLAIN PLAN are permitted, and CTEs are accepted. It also notes connections have readonly status via the list_schemas hint. 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 three short sentences, front-loaded with the core purpose, and every sentence adds value. It avoids fluff and is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description is complete for a query tool. It covers statement types, CTE support, and connection discovery. It does not mention pagination or bind parameters, but those are well-documented in the schema, so the description need not repeat them.
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%, so the baseline is 3. The description adds a little context around the query parameter (read-only, CTE acceptance) and connection (readonly status), but largely repeats what the schema already states. It does not meaningfully enhance parameter understanding 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 executes read-only SQL queries (SELECT and EXPLAIN PLAN only), with CTEs accepted. It distinguishes from sibling tools by emphasizing read-only, which contrasts with insert_query, update_query, delete_query, call_procedure, and execute_unsafe_query.
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: it is for read-only SQL queries, and explicitly says to use list_schemas to see available connections and their readonly status. It does not explicitly name write tools as alternatives, but the read-only restriction and sibling names imply when not to use it.
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?
The description discloses that the tool commits automatically and returns the number of rows updated, adding context beyond the annotations. The destructiveHint annotation already signals destructive behavior, and the description reinforces this while providing useful operational details.
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 short sentences with no wasted words. The first sentence states the primary purpose, the second gives a key constraint, and the third explains the return value. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a simple scope, full schema coverage, an output schema, and annotations, the description covers the essential behavioral aspects. It mentions return value, auto-commit, and connection prerequisite, making it sufficiently complete for an agent to use 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?
The schema descriptions already cover all three parameters (query, params, connection) at 100% coverage. The description does not add significant new meaning beyond the schema, only repeating the requirement for a writable connection already present in the connection parameter description.
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 opens with 'Execute an UPDATE statement,' which clearly specifies the verb and resource. It is distinct from sibling tools like insert_query and delete_query by explicitly focusing on UPDATE operations.
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?
It provides clear context by stating 'Only available on writable connections (readonly=false in list_schemas),' guiding when the tool can be used. It does not explicitly name alternatives, but the constraint plus the tool name makes the usage situation clear.
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 mark the tool as destructive, and the description adds valuable context: 'Commits automatically' and 'Returns the number of rows inserted.' This goes beyond the annotation and clarifies transaction behavior and return value.
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 four short, purposeful sentences with no fluff. It front-loads the core purpose and keeps supplementary details compact.
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?
For a simple insert tool, the description covers purpose, connection requirements, transaction behavior, and return value. An output schema exists, so further return details are unnecessary.
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%, with all three parameters described in the input schema. The description reinforces the connection constraint but doesn't add new parameter meaning beyond the schema, so baseline 3 is appropriate.
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 'Insert a single row into a table,' using a specific verb and resource. It distinguishes itself from sibling tools like update_query and delete_query by focusing on insert-only behavior.
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?
It explicitly says 'Only available on writable connections (readonly=false in list_schemas),' which is a key usage constraint. It doesn't explicitly name alternatives for multi-row inserts, but the sibling tool names imply context.
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?
The description discloses the SQL mechanism (ALTER TRIGGER) and the writable connection requirement, adding behavioral context beyond the annotations. Since destructiveHint is already true, the description does not need to restate that, but it does clarify the exact operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no redundant information. Every sentence earns its place.
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 simplicity, the presence of an output schema, and annotations, this description is complete. It covers the core action and the key constraint (writable connections) without needing to explain return values or error handling.
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 descriptions for all parameters are present and comprehensive (trigger_name example, action values, connection requirements). The description adds no additional parameter-level detail beyond referencing ENABLE/DISABLE, so the baseline of 3 is appropriate.
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 function: 'Enable or disable a trigger via ALTER TRIGGER name ENABLE/DISABLE.' It uses specific verb+resource and distinguishes itself from sibling tools like create_trigger, which creates triggers rather than changing their status.
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 a clear prerequisite: 'Only available on writable connections.' This gives important context for when the tool can be used. It does not explicitly name alternatives or when-not conditions, but the purpose is self-evident given the sibling tool names.
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?
The description adds significant behavioral context beyond the destructiveHint annotation: it explicitly states 'Commits automatically,' which is critical for a procedure that may modify data, and 'Only available on writable connections,' an operational prerequisite. It also clarifies the IN-only parameter limitation. This goes well beyond structured 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: the first sentence states the main purpose, followed by three short sentences covering limitations, commit behavior, and connection requirement. Every sentence adds value with 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?
For a procedure-call tool, the description covers all essential aspects: purpose, parameter limitations, commit behavior, and connection prerequisites. An output schema exists, so return-value details are not needed. The description is complete for an 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—each parameter already has a meaningful description (e.g., params: 'IN parameters as key-value pairs', connection: 'Must have readonly=false'). The tool description adds no new parameter-level information, so baseline 3 is appropriate.
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: 'Call a stored procedure or package procedure via anonymous PL/SQL block.' It uses a specific verb, names the resource type, and distinguishes it from siblings like create_procedure or execute_query.
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 clear usage constraints: 'Supports IN parameters only', 'Commits automatically', and 'Only available on writable connections.' This tells the agent when the tool is appropriate and what conditions must be met, though no explicit alternatives are named.
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?
The description discloses important behaviors beyond annotations: automatic commit, availability only on writable connections, and return of the deleted row count. Annotations only indicate destructive=true, so the description adds significant context.
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 short sentences, each carrying distinct information: purpose, commit behavior, availability, and return value. No redundancy or filler.
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?
For a 3-parameter destructive operation with full schema coverage and an output schema, the description covers all necessary context: purpose, commit behavior, connection requirements, and return value. It is sufficient for an agent to select and invoke the tool 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%, meaning all three parameters (query, params, connection) are well-documented in the input schema. The description repeats the connection constraint but adds no new parameter-level meaning beyond what the schema already provides.
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 'Execute a DELETE statement,' which is a specific verb and resource. It distinguishes from siblings like insert_query and update_query by specifying DELETE. It also adds commit behavior and return value.
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: DELETE statements only, available only on writable connections. It does not explicitly mention alternatives or exclusions, but the constraint on readonly connections is a clear usage guideline. The tool's name and description imply its purpose relative to siblings.
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 the destructiveHint annotation, the description adds crucial behavior: unrestricted SQL, CSV output for SELECT, row count for DML, and the auto_commit=false dry-run rollback mechanism. It also notes the writable connection requirement.
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 the purpose, then output behavior, then dry-run and connection constraint. Every sentence adds value; no redundancy or 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?
Given the potentially destructive nature, the description covers execution scope, return types, dry-run safety mechanism, and a constraint. With a rich schema and output schema, this is fully adequate for an agent to select 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?
Schema coverage is 100%, so baseline is 3. The description enriches meaning by explaining that auto_commit=false rolls back after reporting affected row count and clarifies SQL result types, adding value beyond schema 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 clearly states 'Execute any SQL statement without restrictions' with specific output behavior (SELECT returns CSV; DML returns row count). This distinguishes it from sibling tools like execute_query and the dedicated insert/update/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through 'without restrictions' and 'Only available on writable connections,' but no explicit when/when-not guidance or named alternatives is provided. The dry-run hint gives parameter usage guidance but not tool selection context.
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 the description adds that the output is CSV with specific columns, providing useful behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action and includes output format and columns without 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?
The tool is simple, with no parameters, read-only annotation, and an output schema. The description fully covers the output format and columns, making it complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description does not need to explain parameter semantics. The baseline for zero-parameter tools is 4, which applies here.
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 it lists available Sankhya connections with auth_url, base_url, and default status. It clearly distinguishes from sibling tools that handle schemas, queries, and procedures.
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 clearly indicates its purpose as listing connections, which is distinct from query/procedure tools. It does not explicitly mention alternatives but the context is clear enough for selection.
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, but the description adds useful context by explaining the output includes readonly status and how that determines tool availability. It does not contradict annotations. No mention of pagination or limits, but the tool is a simple listing operation with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and uses a clear bullet-like list for tool availability. Every sentence adds value with no redundancy or 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?
Given the tool has no parameters, an output schema exists (as per context), and sibling tools are numerous, the description sufficiently covers what the tool does and how to use its output for selecting subsequent tools. It is complete for an agent to 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?
The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters, but it adds value by describing the output fields (descriptions and readonly status) which aids the agent in interpreting the return value.
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 function: 'List available Oracle connections/schemas with descriptions and readonly status.' It uses a specific verb ('List') and identifies the resource (Oracle connections/schemas) and the output attributes (descriptions, readonly status). This differentiates it from sibling tools like sankhya_list_connections by specifying Oracle and readonly status.
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 usage guidance: 'Use readonly field to determine which tools are available' and then enumerates which tools require readonly=false. This tells the agent when to use this tool (i.e., to discover available connections and subsequently choose an appropriate query/update tool) and how to interpret the output for decision-making.
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:

[![SankhyaMCP MCP server](https://glama.ai/mcp/servers/delt4d/SankhyaMCP/badges/card.svg)](https://glama.ai/mcp/servers/delt4d/SankhyaMCP)

Score Badge

Copy to your README.md:

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

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/delt4d/SankhyaMCP'

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