find_match
Find a football/basketball fixture by natural-language name. Args: query: e.g. "Man City vs Arsenal" or a single team name. sport: optional filter — "football" or "basketball". date: optional UTC date "YYYY-MM-DD" to disambiguate same-name fixtures. Returns the best-matching event (with id, teams...
This record as markdown: /tools/dev-infersports-infersports/find-match.md
What find_match does on Infersports
AI agents call find_match to retrieve information from Infersports without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
date | object | — | |
query | string | Yes | |
sport | object | — |
Parameters from the server's own tool schema.
Why find_match is rated Low
find_match performs a search/lookup operation that retrieves and returns fixture information without side effects. It acts as a query interface to find specific events, which is characteristic of Read category tools. The returned event_id is meant to be used with other tools downstream (get_match_odds, compare_lines), but find_match itself only queries and returns data.
From the tool's definition Tool retrieves matching football/basketball fixtures by natural-language query and returns event data (id, teams, league, kickoff, live score, clock). No modification, deletion, or financial transaction occurs.
Attacks that exploit this kind of access
The rule that runs find_match safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Infersports, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For find_match, this is the rule to start with:
find_match is read-only, so it stays allowed. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Infersports, apply this rule, and every find_match call is checked against it from then on.
Questions about find_match
Find a football/basketball fixture by natural-language name. Args: query: e.g. "Man City vs Arsenal" or a single team name. sport: optional filter — "football" or "basketball". date: optional UTC date "YYYY-MM-DD" to disambiguate same-name fixtures. Returns the best-matching event (with id, teams, league, kickoff, live score, the live match clock e.g. "2h 47" or "ht", and a confidence score) plus alternatives. Use the returned event_id with get_match_odds / compare_lines. A decision block tells you whether it's safe_to_proceed and the suggested next_action (or ask_user when ambiguous). It is categorised as a Read tool in the Infersports MCP Server, which means it retrieves data without modifying state.
find_match accepts 3 parameters: date, query, sport. Required: query. The full parameter table on this page comes from the server's own tool schema.
Register the Infersports MCP server in PolicyLayer and add a rule for find_match: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Infersports. Nothing to install.
find_match is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the find_match rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for find_match. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
find_match is provided by the Infersports MCP server (https://api.infersports.dev/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Infersports, and thousands of servers like it.
This server
Across the catalogue