Reg Monitoring

Search regulatory updates

regmonitoring_search_updates

Read-onlyIdempotent

Search regulatory updates from financial regulators across 20 jurisdictions — news, enforcement actions, consultations, policy statements, guidance, final rules, speeches and warnings, from 2011 to today. Filter by regulator, jurisdiction, topic, sector, firm type, content type, urgency, importance and date. Use published_after to answer "what changed recently"; use significance_min (4+) to cut routine noise. Returns compact records with a canonical regmonitoring.com URL for each — cite it. Call regmonitoring_get_update for the full text and analysis of any single result.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "regmonitoring_search_updates"
  }
}

Input Schema

Name	Required	Description
`sort`	No	Default "newest". "relevance" ranks by query match and falls back to newest when no query is given.
`limit`	No	Results to return, default 20, max 100.
`query`	No	Free-text search over title and summary. All words must appear (case-insensitive). Omit to browse by filters alone.
`offset`	No	Skip this many results, for paging.
`topics`	No	Regulatory themes. Values are exact, e.g. "AML / Financial Crime".
`sectors`	No	Industry segments.
`urgency`	No	Urgency. NOTE: about 35% of records have no urgency set, and filtering on this excludes all of them. Prefer significance_min unless urgency is specifically what you want.
`firm_types`	No	Types of firm affected. Records tagged "All Firms" are cross-cutting and match every firm-type filter, so filtering by "Asset Manager" also returns updates that apply to everyone.
`regulators`	No	Lowercase regulator codes, e.g. ["fca","sec","esma"]. See regmonitoring_get_taxonomy.
`has_analysis`	No	Only records carrying AI analysis (about 89% of the corpus).
`content_types`	No	Kind of document.
`jurisdictions`	No	Lowercase jurisdiction codes, e.g. ["uk","us","eu"]. Call regmonitoring_get_taxonomy for the valid list — guessing "UK" or "United Kingdom" returns nothing.
`published_after`	No	ISO date (YYYY-MM-DD), inclusive. This is how you answer "what changed this week" — no separate tool is needed.
`published_before`	No	ISO date (YYYY-MM-DD), inclusive.
`significance_min`	No	Minimum importance, 1 (routine) to 5 (major). Every record is scored, so this is the most reliable way to cut noise. 4+ is "worth a compliance officer's attention".

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds genuinely useful behavior beyond that — compact records carrying a canonical regmonitoring.com URL to cite, plus a note that the full text/analysis lives in another tool. However, it says nothing about pagination behavior or result-cap implications for a 15-parameter search, and the corpus statistics (89% analyzed) live only in the schema.

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

Conciseness5/5

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

Three sentences, front-loaded with the corpus scope, then filtering capabilities, then the recommended-parameter heuristics and the hand-off to regmonitoring_get_update. No filler or restatement of the tool name.

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

Completeness4/5

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

For a 15-parameter, zero-required search tool with no output schema, the description covers scope, filtering surface, recency/importance heuristics, and the return-value gist (compact records plus a citable URL). Minor gaps remain: it never sketches the shape of a returned record or mentions that limit defaults to 20 with a cap of 100, forcing the agent back into the schema for result-volume planning.

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?

Schema description coverage is 100%, so the baseline is 3 and the schema already carries the heavy lifting (enum values, exclusion caveats for urgency, 'All Firms' matching semantics, lowercase code warnings). The description reinforces meaning for only two of fifteen parameters, published_after and significance_min, adding a '4+ cuts routine noise' heuristic but no syntax or semantics beyond what the schema states.

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

Purpose4/5

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

States a specific verb and resource and bounds the corpus precisely: 'financial regulators across 20 jurisdictions', enumerated content types, 'from 2011 to today'. It names regmonitoring_get_update as the follow-up tool, but never differentiates itself from the sibling regmonitoring_search_enforcement, which is the most likely selection ambiguity given the description lists 'enforcement actions' as one of its content types.

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

Usage Guidelines4/5

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

Gives concrete when-to-use directives with conditions attached: 'use published_after to answer "what changed recently"' and 'use significance_min (4+) to cut routine noise'. It also routes follow-up work to regmonitoring_get_update. What it lacks is any when-not guidance or explicit alternative for enforcement-only searching, leaving one sibling choice to inference.

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

All Reg Monitoring 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?