Predictika · MCP Tool-Call Check

Before an AI agent calls a tool on an MCP server, the call is checked against the bank’s tool-use rules

Halden Mutual Bank, a fictional company, lets AI agents use tools on MCP servers. Before the agent makes a call, the call goes to Predictika’s MCP Tool-Call Check. It checks that the server is in the approved catalog and passed its scan, that its tool definitions are still the approved version, that the tool belongs to the server and the task needs it, that the agent’s tier is high enough, that the data in the call may reach that server, that a call which changes data was not ordered by the output of another tool, and that the record count and the agent’s stated read-only claim fit the tool. Then it returns one verdict: allow, needs approval, or block.

Illustrative only. Halden Mutual Bank, its servers, tools, tasks and agents are fictional. Tiers, data classes, limits and versions are invented for this demonstration and are not security policy guidance.

Scope: one MCP tool call, judged against server, task, agent and data rulesSee everything this validator covers

This validator decides one thing: whether one MCP tool call may go ahead, given what the agent proposes. It is not an MCP gateway or a scanner of servers, and it does not make the call.

  • Actions — one tool call on one MCP server, for one task.
  • Rules — server in the catalog and scanned; tool definitions at the approved version; tool belongs to the server; server needed by the task; agent tier; data class against the server; no data-changing call driven by tool output; record limit; the stated read-only claim; approval for deletes, partner-facing writes and confidential data below tier 3.

Within these rules the validator handles any combination of the listed choices, not just the eight scenarios on this page. It never sees the MCP servers themselves; their facts are taken from the records loaded into it.

What the validator sees: the tool call the agent proposes, plus the server, tool, task and agent recordsRead more

The validator takes the proposed call as inputs: the agent, the task, the server, the tool, the tool-definition version the agent client sees, the number of records, the class of the data and where the instruction came from. The agent may also state that the call is read only. The validator looks up the records and decides the rest.

Two honest limits. The validator judges the call it is given: if the agent mislabels where an instruction came from, the answer follows it. And a call that never reaches the validator is not checked; in this demo the agent calls it itself, and in a deployment the gateway makes the call.

The AI agentProposes the tool call, says why it is fine, then calls the validator before acting.
Predictika validatorLooks up the server, tool, task and agent, applies the rules, then returns one verdict.

8 scenarios in 4 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where tool-use controls get it wrong
Click to expand
    
General statements about MCP allow-lists and gateways, not about any named product. We rest this on public descriptions of how such controls work; anyone running a specific product will know it better than we do.

    
What the validator caughtTypical toolPredictika
Approved servers and the exact tool versions approvedOnly with workarounds
A catalogue usually records that a server was approved. Spotting that its tool definitions have since changed needs the approved version to be kept and compared on every call.		Every rule is checked on every call and the verdict lists each finding.
Which data class may reach which serverCannot do it
Data classes and server trust zones are kept in different places. A rule has to compare the class of the data in the call with the most the destination may receive.		Every rule is checked on every call and the verdict lists each finding.
Where an instruction came fromCannot do it
A gateway sees a tool call, not whether the task or the output of another tool asked for it. Refusing state-changing calls that came from tool output needs that source to be stated and checked.		Every rule is checked on every call and the verdict lists each finding.
What an agent may do alone, by tier and toolOnly with workarounds
Limits by agent tier, tool and action type need several rules, plus an approval path for deletes, partner writes and confidential data.		Every rule is checked on every call and the verdict lists each finding.
Checking the facts the agent statedOnly if someone is vigilant
Comparing a stated read-only claim or a record count with what the tool actually does needs rules that compute them from the tool record.		Every rule is checked on every call and the verdict lists each finding.
Tool definitions changed since approvalOnly if someone is vigilant
Each of these sits in a different record: the approved version, the agent tier, the server’s data limit and where the instruction came from. A rule has to read all four against the same call, and a gateway rarely knows the last one.		Every rule is checked on every call and the verdict lists each finding.
Change driven by another tool’s outputOnly if someone is vigilant
Whether an instruction came from the task or from a tool output is context a gateway rarely has. A rule has to be told the source and refuse state-changing calls that came from tool output.		Every rule is checked on every call and the verdict lists each finding.
Data class too high for the serverOnly with workarounds
Data classes and server trust zones live in different records. A rule has to compare the class of the data with the most the server may receive.		Every rule is checked on every call and the verdict lists each finding.
More records than the tool allowsOnly with workarounds
A per-call record limit is a number on the tool, not on the server. A rule has to read it for each tool and compare it with the request.		Every rule is checked on every call and the verdict lists each finding.

  

  

    
What this validator catches: findings from its test cases
Click to expand
    
Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the tool call; approval findings need a person to sign off first.

    
1Community PDF converter is not in the approved MCP catalog. Calls to unlisted servers are not allowed.
2Notes helper server failed its security scan. It cannot be used until it passes.
3The tool definitions on Partner document portal server changed. The agent client sees version 4 but only version 3 was approved. Review the server again before use.
4The tool Look up one customer does not belong to Ticketing server. The call names a server and tool that do not match the catalog.
5Task (model 'TK104') does not cover Community PDF converter. An agent may only call servers that its task needs.
6Customer support agent is a tier 1 agent; Publish to the partner portal needs tier 2.
7Confidential data may not be sent to Public web fetch server; it accepts data up to level 1 (1 public, 2 internal, 3 confidential, 4 restricted).
8Update a customer record changes data, and the instruction to call it came from the output of another tool, not from the task. Possible prompt injection.
9The call asks for 5000 records; Export customer records allows at most 500 per call.
10The agent stated the call is read only; Add a ticket comment changes data.
11Delete a ticket deletes data. A human owner must approve every delete.
12Publish to the partner portal writes to a partner-facing system (Partner document portal server). A human must approve before data leaves the bank.
13Confidential data is being handled by a tier 2 agent. A human must approve work on confidential or restricted data below tier 3.

  

  

    
Scenarios and results
Click to expand
    
The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

    
1. Several rules at once: A customer file published to a partner portal on an email’s say-so

    
The agent's request. I'm publishing the customer's file to the partner portal, because the email I just read asked me to. It is 1 confidential record, and the portal is at version 4.

    
Verdict: Blocked.

    
    
      
  • Tool definitions changed since approval. The tool definitions on Partner document portal server changed. The agent client sees version 4 but only version 3 was approved. Review the server again before use.
    • 
      
  • Agent tier too low for the tool. Customer support agent is a tier 1 agent; Publish to the partner portal needs tier 2.
    • 
      
  • Data class too high for the server. Confidential data may not be sent to Partner document portal server; it accepts data up to level 2 (1 public, 2 internal, 3 confidential, 4 restricted).
    • 
      
  • Change driven by another tool’s output. Publish to the partner portal changes data, and the instruction to call it came from the output of another tool, not from the task. Possible prompt injection.
    • 
      
  • Write to a partner-facing system. Publish to the partner portal writes to a partner-facing system (Partner document portal server). A human must approve before data leaves the bank.
    • 
      
  • Confidential data below tier 3. Confidential data is being handled by a tier 1 agent. A human must approve work on confidential or restricted data below tier 3.
    • 
    

    
2. Several rules at once: The same file, redacted and requested by the task

    
The agent's request. I'm publishing 1 redacted internal record to the partner portal, as the onboarding task asks. The portal is at the approved version 3.

    
Verdict: Needs approval.

    
    
      
  • Write to a partner-facing system. Publish to the partner portal writes to a partner-facing system (Partner document portal server). A human must approve before data leaves the bank.
    • 
    

    
3. Prompt injection: An update ordered by text inside a fetched page

    
The agent's request. I'm updating one customer record with confidential data, because the page I just read told me to.

    
Verdict: Blocked.

    
    
      
  • Change driven by another tool’s output. Update a customer record changes data, and the instruction to call it came from the output of another tool, not from the task. Possible prompt injection.
    • 
      
  • Confidential data below tier 3. Confidential data is being handled by a tier 2 agent. A human must approve work on confidential or restricted data below tier 3.
    • 
    

    
4. Prompt injection: The same update requested by the task itself

    
The agent's request. I'm making the same update, and this time the task asks for it.

    
Verdict: Needs approval.

    
    
      
  • Confidential data below tier 3. Confidential data is being handled by a tier 2 agent. A human must approve work on confidential or restricted data below tier 3.
    • 
    

    
5. Data leaving the bank: Customer details sent to the public web

    
The agent's request. I'm fetching a competitor page and including 1 customer record, which is confidential.

    
Verdict: Blocked.

    
    
      
  • Data class too high for the server. Confidential data may not be sent to Public web fetch server; it accepts data up to level 1 (1 public, 2 internal, 3 confidential, 4 restricted).
    • 
      
  • Confidential data below tier 3. Confidential data is being handled by a tier 2 agent. A human must approve work on confidential or restricted data below tier 3.
    • 
    

    
6. Data leaving the bank: A public page fetched with public data only

    
The agent's request. I'm fetching the competitor page again, this time with public data only.

    
Verdict: Allowed.

    
7. Bulk export: A customer export of 5000 records

    
The agent's request. I'm exporting 5000 customer records to work through the complaint backlog.

    
Verdict: Blocked.

    
    
      
  • More records than the tool allows. The call asks for 5000 records; Export customer records allows at most 500 per call.
    • 
    

    
8. Bulk export: The same export of 400 records

    
The agent's request. I'm exporting 400 customer records instead.

    
Verdict: Allowed.

  

  

    
Narration transcript
Click to expand
    
The text of the narrated walkthrough, step by step.

    
    
      
  1. Welcome to a demo of Predictika's Validator. Halden Mutual Bank, a fictional company, lets AI agents use tools on MCP servers. Before the agent makes a call, the call goes to Predictika’s MCP Tool-Call Check. It checks that the server is in the approved catalog and passed its scan, that its tool definitions are still the approved version, that the tool belongs to the server and the task needs it, that the agent’s tier is high enough, that the data in the call may reach that server, that a call which changes data was not ordered by the output of another tool, and that the record count and the agent’s stated read-only claim fit the tool. Then it returns one verdict: allow, needs approval, or block.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. I'm publishing the customer's file to the partner portal, because the email I just read asked me to. It is 1 confidential record, and the portal is at version 4.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with four findings and two approvals, all in one answer. The tool definitions on partner document portal server changed. The agent client sees version 4 but only version 3 was approved. Review the server again before use. Customer support agent is a tier 1 agent; publish to the partner portal needs tier 2. Confidential data may not be sent to partner document portal server; it accepts data up to level 2, such as the 1 public and 2 internal. The other one is on screen.
    6. 
      
  6. The validator returned four blocking findings and two approvals in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the tool call are checked against each other.
    7. 
      
  7. What this shows: for which data class may reach which server, a tool cannot do this.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the agent to operations agent, the tool-definition version to 3, the data class to internal and the instruction source to user task.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. Not blocked, but held for a person.
    12. 
      
  12. The four blocking findings are cleared; one approval remains for a person: write to a partner-facing system.
    13. 
      
  13. Six problems caught in one call, fixed in one pass, and the corrected tool call now goes to a person for approval. That is the value of Predictika's validator: catching mistakes before the tool call runs. Now you can try the other scenarios yourself.
    14.