A water operations assistant must call retrieval through a consistent tool interface usable by multiple FM clients. Which approach best standardizes that access?
Select an answer to reveal the explanation.
Short Explanation
Give every FM client the same labeled tool button for ‘search SOPs’ instead of everyone pasting random JSON into prompts. A standard function-calling or MCP-style interface keeps retrieval tidy and reusable.
Full Explanation
A water operations assistant that must expose retrieval to multiple FM clients needs a stable tool contract. Standardized function-calling or MCP-style tool clients give every model the same typed interface to search SOPs—parameters, schemas, and return shapes—rather than pasting ad-hoc JSON into prompts. That standardization improves reuse across clients, enables consistent testing, supports least-privilege tool authorization, and keeps grounding behavior predictable when operators swap or upgrade foundation models.
Pasting raw OpenSearch JSON into every prompt with no shared tool contract fails maintainability, validation, and safety review. Allowing each developer to invent incompatible retrieval side doors per microservice fragments security controls and produces divergent answer quality for the same SOP corpus. Hard-coding one-off SQL strings inside free-text prompts without schemas fails client portability, input validation, and operational change control when the underlying store evolves.
Exam caveat: Tool-calling and shared retrieval interfaces are how professional GenAI apps expose corpus search to multiple FM clients without prompt-side chaos.
Operational check: publish one versioned retrieval tool schema, require all FM clients to call it, authorize the tool via IAM or application roles, integration-test at least two FM clients against the same SOP search tool, and monitor tool error rates separately from model completion errors.