Skip to content
NTPU AI Learn

GoAI 101 · Module 4

Tools, APIs, MCP, and Government Information Systems

Once AI goes from "can talk" to "can query data, call tools, execute tasks," how do you control it?

Start Section 1
  • Duration60 min
  • LevelCore
  • PrerequisiteModules 1-3 recommended first
0 / 5 completed
Sync my progressJoin a session to keep progress across devices and share it with your instructor

Info

After you join, your completed lesson numbers are sent to your instructor together with your learner code, so they can see your progress. Use the codes your instructor gave you, and do not enter your name, company secrets or other personal data. Progress is kept with the rest of that session's data.

Learning objectives

  • Explain the basic concepts of Tool Use, API, and MCP, and the roles of RAG, API, and MCP.
  • Understand how Tool Discovery, Tool Calling, schema, arguments, result, and provenance work.
  • Understand Read/Write permissions and the Least Privilege principle.
  • Identify which tool actions require approval and which are prohibited, and judge integration boundaries and high-impact actions.

Connect: Tool Use, API, MCP

10 min

Tool Use, API, and MCP

AI can call external capabilities through Tool Use, no longer limited to producing text. An API is an existing system-to-system interface; MCP (Model Context Protocol) provides a standardized tool-discovery and tool-calling mechanism, letting different AI systems connect to a variety of tools and systems in a consistent way.

How RAG, API, and MCP divide roles
TechnologyMain roleExample
RAGRetrieves knowledge content to help AI answer questionsPulling relevant regulation text from a knowledge base
APIAn existing, purpose-built interface between systemsA document-tracking system's status-query interface
MCPA standardized tool-discovery and calling mechanism that can connect many toolsAI queries several different systems through MCP without a custom integration for each one

Info

The three are often conflated but play different roles: RAG handles "what to know," API/MCP handle "what can be done or queried." A single use case may use all three.
Check yourself

Which description best explains the difference in role between RAG and API/MCP?

Which description best explains the difference in role between RAG and API/MCP?

Key takeaway: Tool Use moves AI from "can only talk" to "can query data, call tools," but the division of labor (RAG for knowledge, API/MCP for action) must be clear before you can talk about controlling it.

Tool Discovery and Tool Calling

12 min

How Tool Discovery and Tool Calling work

MCP lets AI complete Tool Discovery before actually calling a tool: confirming which tools exist, their purpose, limits, and required parameters. It then uses Tool Calling to pass arguments per the tool's schema, get back a structured result, and mark that result's provenance.

The basic Tool Calling flow
  1. Tool Discovery: confirm which tools are available
  2. Prepare arguments per the schema
  3. Call the tool
  4. Get a structured result
  5. Mark provenance, for human verification
  • Schema: defines what parameters a tool needs, their types, and limits, so AI cannot pass in arbitrary data.
  • Arguments: the actual parameter values AI passes per the schema, which should be loggable and later auditable.
  • Result: the structured output returned after the tool runs, not raw, unprocessed output.
  • Provenance: which system the result came from and at what time it was queried, so a human can verify it afterward.
Check yourself

A tool call's result has no record of the source system or query time, just a text conclusion. What problem does this cause?

A tool call's result has no record of the source system or query time, just a text conclusion. What problem does this cause?

Key takeaway: Every step of Tool Discovery and Tool Calling (schema, arguments, result, provenance) should be inspectable and traceable, not a black-box call.

Permission-control principles

12 min

Core permission-control principles

Core permission-control principles
PrincipleDescription
Read vs. WriteQuerying data is far lower risk than writing or changing it; default to Read, review Write separately
Least PrivilegeAI gets only the minimum permission needed for the task, never more than the task requires
Approval and escalationHigh-impact actions (write, external send, finance, HR) require human approval before execution
Logging and traceabilityEvery tool call should leave a record for later audit
  • Integration boundaries: which systems AI may and may not connect to should be defined clearly at the design stage, not discovered after go-live as "oh, it can actually reach this system too."
  • High-impact actions: external sending, data writes, finance, HR, etc. should default to requiring human approval no matter how simple they look on the surface.
Check yourself

A unit wants to give an AI Agent direct write access to "issue document" in the document-tracking system, reasoning that "it will be faster." Which judgment is most correct?

A unit wants to give an AI Agent direct write access to "issue document" in the document-tracking system, reasoning that "it will be faster." Which judgment is most correct?

Key takeaway: Least Privilege is not "grant as little permission as possible", it is "grant only the permission this specific task actually needs"; every extra bit of permission is a future source of risk.

Government scenario: querying is fine, writing needs approval

14 min

Government scenario: querying is fine, auto-writing is not

Government scenario: querying is fine, auto-writing is not

AI may be authorized to query a document-tracking system's case status (Read), helping a caseworker keep track of progress; it should not be given default authorization to directly change case-closed status or issue a document (Write), that needs human confirmation first. Another example: AI may help prepare a draft official document, but formal issuance requires sign-off by an authorized officer through the statutory process, AI cannot complete formal document issuance on its own.

  • These two examples are two faces of the same principle: "querying" and "preparing" are low-risk actions that can be authorized more loosely; "writing" and "formal issuance" are high-impact actions that must keep a human gate.
  • Even when the draft AI prepares is consistently high quality, there must still be an explicit, non-skippable human step between "draft complete" and "formally in effect."

Warning

A common mistake is thinking "AI does this so well it should just be allowed to finish the whole thing." The risk judgment for tool integration should be based on the scope of impact of the action itself, not on how well AI has performed in the past.
Check yourself

AI-drafted documents have consistently been high quality, and someone proposes letting AI skip human sign-off and issue documents directly going forward. Which judgment is most correct?

AI-drafted documents have consistently been high quality, and someone proposes letting AI skip human sign-off and issue documents directly going forward. Which judgment is most correct?

Key takeaway: Authorization for querying and draft preparation can loosen over time; the human gate on formal writes and outbound issuance does not disappear just because AI has performed well.

Practice and application

12 min

Practice: Can the Agent Use This Tool?

Activity 4 lists every tool or system used in Module 2's workflow and classifies the permission level of each action, filling in the Government AI Tool & Permission Matrix.

  1. List the tools or systems involved
    Include both query-only and execution systems.
  2. Mark each tool's Read/Write
    And mark the data access scope.
  3. Classify each action
    Read / Write / Recommend / Execute / Requires Approval / Prohibited.
  4. Mark the owner and fallback
    Who owns this tool, and what happens if it fails.
  • Government AI Tool & Permission Matrix minimum columns: Tool / System, Purpose, Data Accessed, Action, Read / Write, Role, Permission Scope, Approval Required, Logging Required, Failure Impact, Reversible?, Fallback, Owner.
Check yourself

What does the "Reversible?" field in the Tool & Permission Matrix mainly help judge?

What does the "Reversible?" field in the Tool & Permission Matrix mainly help judge?

Key takeaway: Once every tool action's risk, permission, and recoverability is written down clearly, Module 5's governance design has concrete material to work from, instead of debating "how much AI should be allowed to do" in the abstract.

Save as PDF

What next?