Feature: Monitoring MCP Enhancements

[cboffa13]

Description

This PR enhances the monitoring MCP server. This separates the "Alarms" and the "Metrics" into their own folders. The following tools are now available within the Monitoring MCP Server:

Tool Name	Description	Status
list_alarms	List Alarms in the tenancy	Unchanged
get_compute_metrics	Gets only compute metrics	Unchanged
get_metrics_data	Gets aggregated metric data	New Tool Added
get_available_metrics	Lists the available metrics a user can query on in their tenancy	New Tool Added

Fixes # (issue)

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

You can ask specific or generic questions related to metrics or alarms

• In my tenancy, can you list all my metric namespaces?
• For my compute instance ocid1.instance.oc1.phx.... can you list the VolumeReadOps for the last week?

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[shopewf]

I dont mind the change in structure (i.e. splitting the server up into metrics vs alarms), but im wondering if it would just be simpler for us to keep the normal structure of a server intact and separate them in their files by regions?

It's my preferred way of splitting things up like that because in any code editor you could just collapse all of the alarms section if you only wanted to look at metrics. I typically always collapse every single piece of code that im not actively working on

E.g. server.py

# region alarms
... region tools
# endregion

# region metrics
... metrics tools
# endregion

OR we dont even have to worry about the difference between alarms and metrics. I think of our compute server where we have instances, images, and vnic attachments all together

[shopewf]

Would it make sense for us to pass in a Literal enum here instead?

[shopewf]

Does this parameter get used anywhere?

[shopewf]

This goes for every parameter for this function, but if you pass in a default value (in the case here it's "InstanceMetadataRequests"), it's best to wrap the parameter type in Optional. So in this case it would be
metric: Optional[str] = Field(...)

[shopewf]

How are any namespaces besides this supposed to be determined?