01
Read
Example: Look up an order, stock level, customer or invoice
Approach: Available to signed-in users within their own ERP permissions
AI / MCP Servers
MCP server development services for connecting AI agents to your systems
Your teams want AI assistants and agents that can look things up in the ERP, the CRM and internal databases, and IT wants to know exactly what those agents can touch. Agnotic Technologies builds Model Context Protocol servers that expose your systems as scoped, logged tools, so you decide what every agent can read and do.
Scoped toolsOAuth 2.1 sign-inRead-only by defaultAudit log of every call
Trusted by global innovators
What is MCP server development?
MCP server development is the work of building a Model Context Protocol server: a service that sits in front of your ERP, CRM, databases or file stores and exposes chosen operations to AI applications as named tools and resources. Agnotic Technologies builds MCP servers as an engineering service for your company: we decide with you which records and actions each tool covers, connect the tools to your systems through their own APIs, add sign-in with your identity provider, limit each tool to the scopes a user or agent is allowed, and log every call. Any MCP-capable assistant or agent can then use the same governed connection instead of its own integration.
Do you need one?
Do we need an MCP server to connect AI agents to our systems?
Not always. If one agent in one application needs a few calls to one system, that application can call the system's API directly through function calling. An MCP server pays off when several AI clients, agents or teams need the same systems, because you build and secure the connection once and every client uses it on the same terms.
Agnotic Technologies gives a straight answer on the scoping call, and where a direct integration is enough we build that instead.
Read-only access
How do we let an AI agent read our ERP without letting it change data?
Make read-only a property of the server and the ERP account, not a promise in the prompt: expose only read tools, run them under an ERP role that cannot write, and log every call. These are the layers we put between an agent and your ERP.
| Layer | What we build | Why it matters |
|---|---|---|
| ERP account | A service account or user role in the ERP with read permissions only | Even a faulty tool cannot write if the ERP refuses it |
| Tool list | Only lookup tools, such as order status, stock level or invoice search, marked read-only | The agent never sees a tool that changes data |
| Query limits | Allowed fields, row limits and filters per tool | Stops bulk export of prices, customers or pay data |
| User scope | Tool results filtered to what the signed-in person may see in the ERP | The agent cannot show staff data they could not open themselves |
| Write requests | No write tools, or a separate tool that drafts a change for a person to approve | Changes stay a human decision |
| Audit log | Every call with user, tool, parameters, result size and time | You can show who asked for what |
Tool annotations such as readOnlyHint tell AI clients how a tool behaves, but they are hints. The ERP account and the server code are what actually enforce read-only access.
Permissions
Who controls what an AI agent is allowed to do in our systems?
You do. The MCP server holds the rules: which tools exist, which users and agents may call them, and which calls need a person to approve. The AI model only chooses among the tools it is given. These are the levels we set up with your IT and process owners.
02
Draft
Example: Prepare a purchase requisition, a credit note or an email
Approach: Saved as a draft in the target system for a person to review and post
03
Write with approval
Example: Change a delivery date or release an order
Approach: The call waits for a named approver before it reaches the system
04
Not exposed
Example: Delete records, change prices or edit user rights
Approach: No tool exists, so no agent can do it
Gemini
Can you build our app for Gemini and Google Search?
Yes, we can build your application on Google's Gemini API, connect it to your systems through function calling or a remote MCP server, and ground answers with Google Search where current public web information is needed. This is independent engineering on Google's published APIs, not a Google partnership, and how anything appears inside Google's own products is decided by Google.
- Function calling: Gemini decides when to call your functions and supplies the parameters
- Remote MCP: your MCP server reachable over Streamable HTTP for the Gemini Interactions API
- Grounding with Google Search: answers based on current web content, with citations shown to users
- Your app, in your Google Cloud or Gemini API project and your hosting
- The same MCP server can serve Gemini and other AI clients
One tool call
What happens when an agent calls an MCP tool?
The path every call takes through the server we build, from sign-in to the log entry.
Sign in
The AI client gets an access token from your identity provider for this server, on behalf of the user.
List tools
The server returns only the tools this user or agent is allowed to see.
Call
The model picks a tool and sends parameters; the client shows the call to the user where your rules require it.
Check
The server validates the token, the scope, the parameters and the query limits.
Run
The tool calls your ERP or other system through its API, under the account set for that tool.
Log and return
The result is trimmed to allowed fields, logged and returned to the model.
Server design
What does an MCP server expose?
What we design with you before writing the first tool.
Tools
- Named actions with typed inputs
- Read, draft or approval-gated writes
- Annotations for AI clients
Resources
- Reference data such as item lists or policies
- Documents the model can read
- Cached where the source is slow
Prompts
- Approved templates for common tasks
- Instructions that stay with the server
Security
- OAuth 2.1 with your identity provider
- Scopes per role and per agent
- Rate limits and audit logging
What do we build in an MCP server project?
Server, connectors and controls, handed over as code you own.
MCP server
Tools, resources and prompts over Streamable HTTP or stdio, built to the current specification.
System connectors
ERP, CRM, database and document store connections through their own APIs.
Authorization
OAuth 2.1 sign-in through your identity provider, with tokens checked for this server.
Scopes and roles
Which users, teams and agents can see and call each tool.
Approval steps
Write requests held for a named person before they run.
Audit log
Every call, its parameters, its result size and the user behind it.
Tool testing
Test suites that call each tool the way models do, including bad inputs.
Hosting and monitoring
Deployed in your cloud account with alerts on errors and unusual use.
Failure points
Where do MCP projects go wrong?
Problems we design out from the first release.
Challenge
One broad tool runs any query the model writes.
Agnotic approach
Narrow tools with typed inputs, one per business question.
Challenge
The server uses an admin account for every call.
Agnotic approach
Each tool runs under the least access it needs, and results follow the user's own rights.
Challenge
Read-only depends on the prompt.
Agnotic approach
Read-only is enforced by the ERP account and the tool code.
Challenge
Nobody can say what the agent did yesterday.
Agnotic approach
Every call is logged with the user, tool and parameters.
Challenge
Tool descriptions from other servers are trusted blindly.
Agnotic approach
Only approved servers are connected, and their tools are reviewed before use.
Related builds
Where does an MCP server fit?
The server is the connection layer; these pages cover what sits on either side of it.
AI agent for ERP
The staff-facing assistant that answers order, stock and invoice questions through these tools.
Read-only vs write-back AI agents
When an agent should only read, and when it may write back with controls.
Custom AI agent development
The agents and assistants that call the tools your server exposes.
Custom ERP development
ERP work behind the tools, where your system needs new APIs first.
Facts and sources
What do the MCP specification and Google's documentation say?
The protocol rules our servers follow and Google's documented MCP support, each linked to its source.
The Model Context Protocol specification (version 2026-07-28) uses JSON-RPC 2.0 messages between hosts, clients and servers, and servers can offer clients three features: resources (context and data), prompts (templated messages and workflows) and tools (functions for the AI model to execute).
Source: Model Context Protocol specification, overviewThe MCP tools specification says that, for trust and safety and security, there should always be a human in the loop with the ability to deny tool invocations, and that applications should show which tools are exposed to the AI model.
Source: Model Context Protocol specification, toolsIn the MCP schema, a tool's readOnlyHint annotation means the tool does not modify its environment, but all tool annotations are hints and are not guaranteed to describe the tool's behavior faithfully.
Source: Model Context Protocol specification, schema referenceUnder the MCP authorization specification, a protected MCP server acts as an OAuth 2.1 resource server and must validate that access tokens were issued specifically for it as the intended audience, as described in RFC 8707.
Source: Model Context Protocol specification, authorizationGoogle's Gemini API documentation says its Interactions API can connect to remote MCP servers to give the model access to external tools and services, and that remote MCP works only with Streamable HTTP servers, not Server-Sent Events servers.
Source: Google AI for Developers, Gemini API function calling
Standards
Protocols and standards we build MCP servers with
MCP 2026-07-28JSON-RPC 2.0OAuth 2.1RFC 8707Streamable HTTPOpenAPI
Who it is for
Teams that need governed AI access
Companies giving AI assistants and agents access to business systems for the first time.
Manufacturers and distributors
Order, stock and invoice lookups from the ERP for sales and service staff.
IT and platform teams
One approved connection layer for every AI tool the business adopts.
Software companies
An MCP server so customers' AI clients can use your product's data.
Operations teams
Agents that read several systems and draft work for people to approve.
Scope
What decides the size of an MCP server build?
We do not publish prices. These are the drivers we size on the scoping call.
Systems
Which ERP, CRM, databases or file stores the tools reach, and their APIs.
Tools
How many tools, and how many read, draft or write.
Identity
Your identity provider and how user rights map to tool scopes.
Approvals
Which actions need a person, and who that is.
AI clients
Which assistants, agents or Gemini apps will connect.
Hosting
Your cloud account, network rules and monitoring.
Engagement
How does an MCP server project run?
We start with read tools for one system.
1.
Scoping call
We list the questions staff want answered and the systems that hold the answers.
Scope2.
First release: read tools for one system
A fixed-scope first release: sign-in, a set of read-only tools for one system, scopes and the audit log.
Build3.
More systems and approved writes
More systems, draft and approval-gated tools, and more AI clients, with support after launch.
ScaleFrequently Asked Questions
Any client that supports the Model Context Protocol and the transport the server uses, including desktop assistants, agent frameworks and the Gemini API's remote MCP support. We test the clients you plan to use before go-live.
The server runs in your cloud account or network, and only the results of tool calls go to the AI model. Which model provider receives them, and under what terms, is a choice we make with you.
Yes. Tool scopes and result filters can follow the user's role in your identity provider or the ERP, so an agent working for a user sees only what that user may see.
The protocol defines authorization for HTTP servers, but security depends on how the server is built: narrow tools, least-privilege accounts, token checks, approvals and logging. Those are the parts we build and test.
We do not publish prices. The systems, number and kind of tools, identity setup, approvals, AI clients and hosting decide the size, and we agree a fixed first release on the scoping call.