Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Oracle Server show me the top 5 customers by total purchase amount"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol server to access oracle
https://github.com/user-attachments/assets/dc4e377b-4efb-43e6-85fa-93ed852fe21f
Related MCP server: Oracle MCP Server
To try this in Claude Desktop app, add this to your claude config files:
{
"mcpServers": {
"mcp-server-oracle": {
"command": "uvx",
"args": [
"mcp-server-oracle"
],
"env": {
"ORACLE_CONNECTION_STRING": "username/password@hostname:password/service_name"
}
}
}
}UV (pacakge manager)
Python 3.12+
Claude Desktop
Add the server configuration to your Claude Desktop config file:
MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
Fork the repository from mcp-server-oracle
Create your feature branch
Commit your changes
Push to the branch
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
Get a description of a table in the oracle database"
Args:
table_name (string): The name of the table to describe
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('Get a description') but doesn't disclose behavioral traits such as whether it's read-only, requires permissions, returns structured data, or has rate limits. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter, no annotations, and an output schema exists (which should cover return values), the description is minimally adequate. However, it lacks details on usage context, behavioral traits, and parameter specifics, making it incomplete for optimal agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'table_name' as the parameter, but the schema description coverage is 0%, so the schema provides no additional details. The description adds minimal meaning by specifying it's for a table in the oracle database, but doesn't elaborate on format, constraints, or examples. With 1 parameter and low coverage, this is a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get a description') and resource ('table in the oracle database'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_tables' or 'reqd_query', which might have overlapping or related functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_tables' or 'reqd_query'. The description implies usage for describing a specific table, but lacks explicit context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all tables in the oracle database
Args:
None
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't describe traits like whether it's read-only, requires authentication, has rate limits, or what the output format entails. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The second sentence ('Args: None') is redundant given the schema but not wasteful. It could be slightly more concise by omitting the args note, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters) and the presence of an output schema, the description is minimally adequate. However, with no annotations and no guidance on usage versus siblings, it lacks completeness for effective agent operation, though the output schema mitigates some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the absence of parameters. The description explicitly states 'Args: None', which adds no semantic value beyond the schema but aligns perfectly. Baseline is 4 for 0 parameters, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a list') and resource ('all tables in the oracle database'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'describe_table' or 'reqd_query', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'describe_table' or 'reqd_query'. It lacks any context about use cases, prerequisites, or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute SELECT queries to read data from the oracle database
Args:
query (string): The SELECT query to execute
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for reading data via SELECT queries, which implies it's non-destructive and likely read-only, but it doesn't confirm this or add context on permissions, rate limits, error handling, or output format. The description is minimal and lacks rich behavioral details needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. The two sentences are efficient, but the parameter documentation could be more integrated. There's no wasted text, though it might benefit from slightly more detail to enhance clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a database query tool with one parameter), the description is somewhat complete but has gaps. It explains the purpose and parameter semantics, and an output schema exists (which reduces the need to describe return values). However, without annotations and with minimal behavioral context, it doesn't fully prepare an agent for effective use, especially regarding error cases or performance considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter: 'query (string): The SELECT query to execute.' Since schema description coverage is 0% (the schema only provides a title and type), this compensates by explaining the parameter's purpose and constraint (it must be a SELECT query). However, it doesn't detail syntax, validation rules, or examples, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute SELECT queries to read data from the oracle database.' It specifies the verb ('Execute'), resource ('SELECT queries'), and target ('oracle database'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'describe_table' or 'list_tables' beyond the query execution focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions executing SELECT queries but doesn't specify scenarios where this is preferred over 'describe_table' or 'list_tables', nor does it discuss prerequisites, limitations, or exclusions. Usage is implied through the query type but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: describe_table provides metadata about a specific table, list_tables enumerates all tables, and reqd_query executes SELECT queries to read data. There is no overlap in functionality, and an agent can easily distinguish between them based on their descriptions.
Two tools follow a consistent verb_noun pattern (describe_table, list_tables), but the third tool (reqd_query) deviates with an unconventional name that is less readable and mixes styles. This inconsistency reduces predictability, though the overall set remains understandable.
With only 3 tools, the server feels thin for an Oracle database interface, as it lacks essential operations like INSERT, UPDATE, DELETE, or transaction management. While the tools cover basic read and metadata functions, the count is borderline low for the apparent scope of database interaction.
The tool surface is significantly incomplete for an Oracle database server. It only supports describing tables, listing tables, and executing SELECT queries, missing critical CRUD operations (create, update, delete), schema modifications, and other database management tasks. This will cause agent failures when trying to perform common database workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
GibsonAI MCP server: manage your databases with natural language
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/anpy-j/mcp-oracle'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
