A county agent must query parcel APIs and fee calculators through a consistent tool interface rather than bespoke one-off HTTP glue in every prompt. Which approach best fits that requirement?
Select an answer to reveal the explanation.
Short Explanation
Think USB for tools: one shape of plug, many devices—parcel lookup and fee math both speak the same agent-tool dialect. MCP-style interfaces give you that standard socket with validated parameters. Passwords in prompts or pasting fee PDFs is the opposite of safe integration.
Full Explanation
County agents that must query parcel APIs and fee calculators through a consistent interface—not bespoke HTTP glue in every prompt—should expose those capabilities through a standardized tool protocol (for example MCP-style interfaces) invoked with validated parameters. Shared tool contracts give the agent discoverable functions, typed inputs, and reusable integration across prompts and departments, so permitting and treasury bots call the same parcel and fee capabilities without reinventing request shapes. Embedding raw database passwords in the system prompt so the FM can invent SQL is a severe security anti-pattern and not a tool interface; secrets never belong in prompts. Disabling tools and requiring staff to paste fee tables into chat every time abandons automation and invites transcription error on resident-facing fee advice. Replacing the agent with a static PDF of last year’s fee schedule cannot answer parcel-specific live fee questions when rates or exemptions change mid-year. Exam caveat: “consistent tool interface rather than one-off HTTP glue” points to standardized tool or function protocols with validation—not secrets in prompts, manual paste-ins, or static PDFs. Operational check: publish parcel and fee tool schemas centrally, validate parameters before calling backends, rotate credentials outside prompts, version the tool definitions, and monitor tool error rates separately from FM completion quality.