An Model Context Protocol (MCP) server for OCI Documentation that provides tools to access public OCI documentation and search for content
The server provides two read-only documentation tools with solid naming (verb_noun pattern) and comprehensive descriptions. However, parameter documentation is inconsistent, output schemas are not formally documented, and error handling lacks recovery guidance. The tools follow good composition principles (single responsibility) but fall short of production-grade polish.
Fetch an OCI documentation page url and return content partially as markdown. ## Handling Long Documents If the response indicates the document was truncated, you have several options: 1. **Continue Reading**: Make another call with `start_index` set to retrieve the next portion of the document. 2. **Stop Early**: If you've already found the specific information needed, you can stop reading
Search OCI documentation based on a search phrase. ## Usage This tool searches OCI documentation pages matching your search phrase. Use it to find relevant documentation urls about OCI Productswhen you don't have a specific URL. ## Search Tips - Use specific product name/technical terms rather than general phrases - Include service names to narrow results (e.g., "OCI Object Storage bucket versioning" instead of just "versioning") - Use quotes for exact phrase matching (e.g., "Using Instance Configurations and Instance Pools")
Output schemas not documented. Both tools return string (JSON) but LLMs cannot infer the structure of returned fields (pagination, results array, content metadata). Documentation should specify: for search_documentation, what fields appear in results (url, title, description, etc.); for read_documentation, what metadata indicates truncation and how to compute next start_index.
Error handling lacks recovery guidance. Both tools catch exceptions and return generic fallback strings ('No search results found', 'Error searching OCI docs'). Per pattern:recovery-guide, error responses should tell the LLM what to do next: e.g., 'Search failed: URL may be malformed. Verify with oci_search_documentation() first.' Currently ctx.error() is called but the returned string does not guide recovery.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 77 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 57 | - | v1 |
oci_read_documentation parameter 'start_index' lacks clarity on units. Description says 'line number' but the docstring later mentions 'character index'. For a 10,000-line document, ambiguity forces the LLM to guess, risking incorrect pagination. State explicitly: 'Line number (0-indexed) where content starts. Each line is separated by newline.'
oci_search_documentation lacks documentation of pagination semantics. The tool accepts 'page' and 'limit' but does not explain: Is 'page 2, limit 3' results 4-6 or 7-9? Is there a total_count in the response? Should the LLM stop when results.length < limit? Without this, multi-page iteration is error-prone.
Parameter 'max_lines' in oci_read_documentation has validation constraint 'lt=1000000' (less than, not less-or-equal). This means max_lines=999999 is valid but max_lines=1000000 is rejected silently. Use 'le=999999' or document in description: 'Maximum 999,999 lines per request.'