OCI Load Balancer Log MCP Server

Server Quality Checklist

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: searching logs by different criteria (country, IP, location), getting aggregate analytics, listing unique IPs, top IPs, and IPs grouped by country. Even overlapping tools like list_unique_ips and get_top_ips differ in scope (all vs. top N) and output details.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with lowercase and underscores: search_logs_by_*, get_traffic_analytics, list_unique_ips, get_top_ips, get_ips_by_country. The verbs (search, get, list) are clear and used consistently.
Tool Count5/5
Seven tools is an appropriate size for a log analysis server. Each tool provides a distinct function without being redundant, and the count is neither too sparse nor overwhelming for the domain.
Completeness4/5
The tool set covers common log search and analytics operations: filtering by country/IP/location, aggregate traffic stats, and IP-focused queries. Minor gaps exist such as no explicit search by status code or user-agent, but the core workflows for analyzing load balancer logs are well covered.
Average 3/5 across 7 of 7 tools scored. Lowest: 2.4/5.
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
This repository is licensed under GPL 3.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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states that it gets statistics, but nothing about pagination, rate limits, required permissions, grouping behavior, or how results are ordered. The description adds no behavioral context beyond the basic read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the key action and resource, making it easy to parse. However, the extreme brevity borders on under-specification, so it is not a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, sibling tools, and no annotations, the description is insufficient for an agent to invoke it correctly. It does not explain when to use it, what the parameters mean, or what type of aggregated output to expect, despite an output schema existing. The minimal content leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema reference coverage is 0%, meaning the description provides no explanation for parameters like limit, group_by, or time_range. While defaults (1000, 'country', '24h') hint at meaning, the agent cannot determine valid values for group_by or the effect of limit and time_range without external knowledge. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get aggregated traffic statistics from OCI Load Balancer logs' specifies an action (get) and resource (OCI Load Balancer logs), but 'aggregated traffic statistics' is vague and does not clearly differentiate from sibling tools like get_top_ips or get_ips_by_country. It lacks specificity about what dimensions or metrics are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the sibling search and IP analysis tools. No exclusions, prerequisites, or alternative recommendations are mentioned, leaving the agent to infer usage solely from the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It implies a read-only search operation, but there is no mention of what the output contains, whether results are paginated or limited, or any side effects or required permissions. The description adds minimal behavioral insight beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is under-specified, lacking necessary context and behavioral details. It earns a middle score because it is efficient but incomplete for a tool with 6 parameters and a search function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no annotations, and only a one-sentence description. It does not provide usage context, alternatives, or behavior beyond the basic action. The existence of an output schema helps, but the description itself is insufficient for an agent to understand when and how to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the parameters have no explanatory descriptions. The tool description does not compensate by explaining what parameters like lat_min, lon_max, limit, or time_range mean or how they interact. The parameter names are self-explanatory to an extent, but the description provides no added semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches OCI Load Balancer logs within geographic bounds, using a specific verb and resource. It distinguishes itself from siblings like search_logs_by_country and search_logs_by_ip by the geographic bounds concept, though it does not explicitly name alternatives. This is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention how 'search_logs_by_country' or 'search_logs_by_ip' might be more appropriate for certain scenarios, nor does it suggest prerequisites or typical use cases. There is no explicit exclusion or when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral context. It discloses the output fields and optional country filters but omits critical behaviors such as the default limit of 500 (contradicting 'all' IPs), the effect of time_range, and how country vs country_code filtering interacts. No side effects or permissions are mentioned.
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-loads the core function, and adds the filter option without unnecessary words. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 optional parameters, an output schema, and no annotations, but the description only covers the basic output and country filters. It fails to mention time_range and limit behavior, making it incomplete for users needing full operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions (0% coverage), so the description must explain all parameters. It only clarifies the 'country' and 'country_code' filters, leaving 'limit' and 'time_range' unexplained. This is a significant gap for a tool with default values affecting behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('unique IP addresses'), with details on returned fields (request count, country, city, ISP, protocols). It does not explicitly differentiate from sibling tools like get_ips_by_country or get_top_ips, despite overlapping filter options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling tools (e.g., search_logs_by_ip, get_ips_by_country). It does not mention exclusions or prerequisites such as required time range or how to choose between country and country_code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic output and does not mention limitations like how sample_limit affects results, whether ranking is exact or approximate, or any performance or caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core function without filler. It is efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal to be complete for an analytics tool. It omits the role of sample_limit, any caveats about how request counts are computed, and does not clarify when this tool is preferable over sibling tools. While the output schema likely covers return values, other context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains top_n and time_range indirectly ('top N IP addresses', 'given time range'), but completely omits sample_limit. This leaves a significant parameter unexplained.
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 returns the top N IP addresses ranked by request count over a time range, which is a specific verb+resource+scope. This distinguishes it from sibling tools like search_logs_by_ip or list_unique_ips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_unique_ips or search_logs_by_ip. It lacks exclusions, prerequisites, or context that would help an agent choose it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that logs are searched, without mentioning whether results are raw logs or aggregated statistics, how time_range affects results, pagination, or any 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 a single, compact sentence with no filler words. It gets straight to the point and is appropriately concise for a tool with a clear primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having 4 optional parameters, an output schema, and no annotations, the description is only one sentence long. It fails to mention half the parameters, any default behaviors, or usage context, making it incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 4 parameters. It only mentions 'country' and 'country_code', omitting 'limit' and 'time_range' entirely, and does not clarify the format or relationship between these parameters.
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 specifies the action ('Search'), the resource ('OCI Load Balancer logs'), and the filtering dimension ('by country or country code'). This clearly distinguishes it from sibling tools like search_logs_by_ip and search_logs_by_location, which filter by different criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as search_logs_by_ip or search_logs_by_location. The description only states what the tool does, leaving the agent to infer suitability from the name and filter criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the grouping and totals behavior, which is useful. However, it does not mention whether the operation is read-only, how time_range affects data, or any limitations. The description is not misleading but lacks depth.
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?
Two short sentences that front-load the core action and follow with a use case. Every word contributes value; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are not the issue. However, with no parameter semantics and no annotations, the description is insufficient for correct invocation. The tool has two optional parameters whose behavior is unexplained, and there is no guidance on how they interact with the grouping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'limit' or 'time_range' parameters. The agent is left to infer their meaning from parameter names and defaults, which is insufficient.
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 action ('Return unique IP addresses grouped by country') and the per-country totals. It distinguishes itself from sibling tools like search_logs_by_* which filter logs, and list_unique_ips which likely returns ungrouped IPs.
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 a clear use case: 'Useful for understanding which countries have the most unique sources.' This gives context for when to use the tool. However, it does not explicitly mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the search action and filter fields, omitting how the two IP filters interact, whether it supports CIDR, or any rate limits or result ordering. This leaves significant ambiguity for a tool with no annotation support.
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, front-loaded sentence with no unnecessary detail. It efficiently conveys the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is succinct but incomplete for a tool with 4 optional parameters and no annotations. It does not specify the relationship between ip_address and ip_range, the format of time_range, or any behavioral details beyond the search. The presence of an output schema mitigates the need to describe return values, but the tool's usage context is only partially covered.
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 0%, so the description must compensate. It clarifies that ip_range is a 'prefix' and that the tool searches by IP address or range, which adds meaning beyond the parameter names. However, it does not explain the limit or time_range parameters, leaving gaps in full parameter understanding.
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 OCI Load Balancer logs by IP address or IP range, with a specific verb (Search) and resource (OCI Load Balancer logs). This distinguishes it from sibling tools that search by country or location.
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 implies its usage: use when you need to search logs by IP address or prefix. However, it does not explicitly mention when not to use this tool or name alternative sibling tools, so clear context is provided but exclusions are absent.
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:

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

Score Badge

Copy to your README.md:

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

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/mamorett/oci_lb_log_custom_mcp'

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