Ghana Scam Check

Check a message for known scams

scams.check_message

Read-only

Use this when someone in Ghana shares a text, a WhatsApp message or an account of a phone call about mobile money, a bank, a prize, a job, an investment, a delivery or a request for money, and wants to know whether it looks like a known fraud. It returns the fraud patterns the message resembles, what to do, and where to report in Ghana, each with its source. Do not use it to tell someone a message is safe, for fraud outside Ghana, or to trace or recover money. Do not pass PINs or one-time codes to it: leave them out of the message.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "message": "<message>"
    },
    "name": "scams.check_message"
  }
}

Input Schema

Name	Required	Description	Default
`message`	Yes	The message as received, or a short account of the call. Leave out any PIN or code.

Output Schema

Name	Required	Description	Default
`limits`	Yes
`report_to`	Yes
`resembles`	Yes
`explore_url`	No
`warning_signs`	Yes
`sources_read_on`	Yes
`standing_advice`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly and openWorld=false, so the bar is lower, yet the description still adds real behavior: it returns the fraud patterns matched, recommended actions, and reporting destinations in Ghana, each with its source. It also discloses an important safety limitation — the tool will not vouch that a message is safe — which is exactly the kind of expectation-setting annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the trigger, then the return, then exclusions — a sensible order with no filler sentences. The long enumeration of scam categories is the one place it could be tightened, though the breadth plausibly aids retrieval.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only lookup with an output schema, the definition covers everything needed to invoke it correctly: who it is for, what may be passed, what will not be passed back, and the misuse cases. Return-value detail is left to the output schema, which is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter and schema coverage is 100%, with the schema already saying 'The message as received, or a short account of the call. Leave out any PIN or code.' The description's instruction to omit PINs and one-time codes restates the schema rather than adding meaning about format, truncation, or length limits. Baseline 3 is right for a single fully documented parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action (check whether a shared message looks like a known fraud) plus the exact input forms it covers — text, WhatsApp message, or a spoken account of a call — and the subject matter. It also enumerates the relevant scam categories (mobile money, bank, prize, job, investment, delivery, money request) and states what comes back, so an agent can match a user request without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The trigger condition is explicit ('Use this when someone in Ghana shares...') and it is bounded by three named exclusions: don't use it to declare a message safe, not for fraud outside Ghana, not to trace or recover money. That is the when/when-not pattern, which is rare and valuable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Ghana Scam Check tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?