AI Agents Inside a Platform vs External MCP Integrations in Education

Two architectures#

As AI assistants become common in teaching, a practical architecture question has appeared. Where should the agent live?

Built-in agents. The platform vendor builds assistants into the product. An instructor opens an assignment and asks the assistant for a draft rubric. The assistant runs inside the product, reads what the product allows for that user and writes drafts into the product's own forms.

External assistants over MCP. The Model Context Protocol is an open standard for connecting AI applications to external systems, including data sources, tools and workflows. A platform can publish an MCP server, and an assistant that the user already uses, such as a general AI chat application, can connect to it. The assistant then reads data and calls actions the server exposes.

Anthropic's engineering guide to agents separates workflows, where models and tools follow predefined code paths, from agents, where the model directs its own tool use. Both architectures can be built either way. The difference this article addresses is where the agent runs and who controls it.

Side by side#

Strengths of built-in agents#

• Product context. The assistant sees the screen the user is on and the forms they are editing.
• Enforcement close to the data. Permissions and approvals are part of the product's own design, so the assistant cannot do more than the signed-in user could.
• One review. A single vendor, a single data agreement and a single audit trail are simpler for a privacy office to assess.
• Less setup. Faculty use the assistant without configuring anything.

Strengths of external MCP integrations#

• Choice. Users and institutions can pick the assistant they prefer or have already licensed.
• Composition. One request can span systems, for example creating an activity in an assessment tool and an assignment in the LMS.
• Automation. Technical staff can build repeatable workflows.
• Portability. Moving to a different assistant does not require a new product.

Risks to manage#

In both architectures#

• Prompt injection. Text from students, documents or web pages can contain instructions aimed at the model. A system should treat such content as data and not as commands. This risk exists wherever a model reads untrusted text and can take actions.
• Wrong answers and wrong actions. An agent can misread a request. Approvals for consequential actions reduce the harm.
• Over-broad access. An agent that can read everything a user can read may expose more than intended.

More pronounced with external assistants#

• Data flows to another provider. Student data returned through MCP may pass to the assistant's provider. That provider needs to be covered by your institution's data agreements, including under FERPA.
• Scoping depends on configuration. A server that exposes broad read access, combined with a broadly permitted assistant, can reach data the user did not mean to share.
• Inconsistent approvals. An assistant may call a tool without the confirmation step a product's own interface would require.
• Audit gaps. Reconstructing what happened across an assistant and several servers is harder.

More pronounced with built-in agents#

• Lock-in. You use the vendor's assistant and model choices.
• Less flexibility. Only the vendor's workflows are available.
• Opacity. You depend on the vendor to explain what the agent can do.

Questions for institutions#

1. Which agents can read or write student records, and under which agreements?
2. What can each agent do without a person's approval?
3. How are permissions tied to the signed-in user's role?
4. Where are prompts, outputs and logs stored, and for how long?
5. How is untrusted student text separated from instructions?
6. Can an administrator turn an agent or an MCP connection off?
7. Who is accountable when an agent makes a mistake?

Our overview of AI agents in higher education gives the wider checklist, and the blog essay on what agentic AI in education actually requires discusses governance in more depth.

What exists today#

Different vendors have chosen different approaches, and the picture changes. Tough Tongue AI states in its blog that it ships an MCP server and agent skills, and describes combining it with third-party Canvas MCP servers. Rocketproof.ai takes the built-in route: its assistants run inside the platform, and Rocketproof.ai does not currently offer a public API or an MCP server for connecting external assistants. If your workflow depends on an external assistant operating a product, ask each vendor what it supports now. Roadmap statements are not features.

Choosing#

Neither architecture is universally better. A department that wants faculty to start quickly with a single data agreement may prefer built-in agents. A team with technical staff, an existing assistant license and a need to automate across systems may want MCP. Many institutions will end up with both.

Where Rocketproof.ai fits#

Rocketproof.ai includes built-in assistants that draft assignments, simulations, rubrics, question sets and course structures and that analyze course and submission results. They run inside the signed-in user's role and course access. They draft and advise, and a person saves, publishes and grades. The built-in AI agents page lists them, and the agentic AI in education page explains the design principles.