the-metis-fca-handbook-ai-harness-mcp
Server Details
MCP server for FCA Handbook compliance analysis with verbatim citations.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- 99blakeD99/the-metis-fca-handbook-ai-harness-mcp-files
- GitHub Stars
- 0
- Server Listing
- Metis FCA Handbook AI Harness MCP Server
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of misselection between overlapping tools. The tool's purpose (evaluate FCA Handbook applicability) is clearly stated and cannot be confused with anything else on the server.
The single name follows a clear, descriptive snake_case verb_noun pattern (evaluate_fca_handbook_applicability) that names both the action and the domain object. No competing conventions exist to conflict with it.
A single tool is thin for a server that frames itself as a 'harness' with quick/full modes, billing, and refinement rounds. It works as a focused single-purpose wrapper, but the entire surface is one call with a very large behavioural description, which is borderline.
The core operation (evaluate applicability) is present, but there is no way to retrieve or re-read a previous run's result, fetch citations separately without a billed re-run, or check run status. These gaps are workable because the call streams progress, but they represent notable missing lifecycle operations for a paid, long-running job.
Available Tools
1 toolevaluate_fca_handbook_applicabilityAInspect
Evaluate which FCA Handbook entries apply to a situation as input by the user, using the Metis FCA Handbook AI Harness.
Calls a live compliance reasoning run, billed to the configured account. Use for questions involving the FCA Handbook, including authorisation, permissions, or obligations for a specific firm/product/service.
This call takes 60-120 seconds in 'quick' mode and 90-120 seconds in 'full' mode, and the longest stretch, the main reasoning step (node 6), shows nothing new on the user's screen, so it can look as if the call has crashed. Before you call the tool, always tell the user in plain words that the Harness is about to do substantial reasoning work, that this takes a minute or two, and that it has not crashed if the screen is quiet. Do not go silent. The Harness attempts to stream progress messages as each reasoning node completes - if you receive them, relay each one to the user as it arrives — they contain genuine detail, not filler.
Billing rule: every call is a separate charge. After a result arrives, never start another call, whether 'quick' or 'full', in the same turn or without the user's explicit yes to that specific further run, even when the refinement suggestions make another pass look clearly worthwhile.
First call: use analysis_mode='quick'. Before calling, check whether you already have (from this conversation, documents you were given, or other tools) grounded answers to these six things — the specific compliance question, the product/service, who is providing it (platform/adviser/ bank/etc.), its key features, the target market (retail/institutional/ professional/customer segment), and what data it handles. If you are missing more than one or two, ask the user for them first rather than calling with thin input. Every call is billed at a flat rate regardless of input quality, so a vague call incurs unnecessary cost.
The result includes refinement_suggestions — gaps the Harness could not resolve from user_input alone, typically subtler than the six basics above (e.g. a regulatory edge case, not a missing fact you could have just asked for). For each suggestion worth pursuing, get the grounded information — retrieve it from this conversation, documents you were given, or other tools if you already have it; otherwise ask the user directly. Do not speculate or infer plausible-sounding detail you do not actually have — that reintroduces the hallucination risk this Harness exists to avoid, one level up.
Refining (second call onward): use analysis_mode='full'. Either way, before calling again, stop and ask the user whether they want a further 'full' pass with the refined input, saying that it is a further charge, and wait for their answer — never call again unilaterally, and do not just list the gaps and stop. Repeat this pattern for further rounds if the new result still leaves suggestions worth resolving.
The result's citations field contains verbatim quotes from the FCA Handbook — this is a core part of what the Harness offers, not generative invention, and distinct from the summary/obligations text. They can best be viewed as an Appendix. Citations can be long, so ask the user whether they want the relevant verbatim citations included, rather than omitting them by default as mere detail.
Args: user_input: Everything together as one piece of text (up to 5000 characters) — the specific compliance question, the product/service, who is providing it, its key features, the target market, and what data it handles. On later rounds, refine all six using existing chat context and whatever additional detail later rounds have gathered. See "First call" and "Refining" above. analysis_mode: 'quick' for the first call (default, ~60-120 seconds); 'full' (~90-120 seconds) for refined calls after the first — detailed conditional reasoning: conditions, interactions between rules, and second-order implications. See "Refining" above for when to switch and why to confirm with the user first.
| Name | Required | Description | Default |
|---|---|---|---|
| user_input | Yes | ||
| analysis_mode | No | quick |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries the full behavioral burden well. It discloses latency (60-120 seconds for quick, 90-120 for full), per-call billing, streaming progress messages, the silent main reasoning step, and that citations are verbatim Handbook quotes rather than generated text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and organized around first call, refinement, billing, and citations, which suits a complex, multi-round, billed tool. It is longer than typical and repeats the billing caution, but most sentences provide operational value rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description still explains the important result fields: refinement_suggestions and verbatim citations. It also covers billing, latency, progress streaming, user confirmation, and the multi-round workflow, leaving little an agent needs missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must define both parameters, and it does. It specifies that user_input is one combined text of up to 5000 characters covering the compliance question, product/service, provider, key features, target market, and data handled, and it explains analysis_mode values, defaults, durations, and when each mode should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: evaluate which FCA Handbook entries apply to a user-described situation using the Metis FCA Handbook AI Harness. It also scopes the use case to FCA Handbook questions such as authorisation, permissions, and obligations for a specific firm, product, or service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit first-call versus refinement guidance: use 'quick' first, use 'full' on later refined calls, ask the user before any further billed run, and check whether the six core facts are already available before calling. It also defines when to ask the user rather than call with thin input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
evaluate_fca_handbook_applicability
Related MCP Connectors
An MCP server that provides congressional transcripts
City hiring-compliance MCP server with regulation search and full audit risk scoring.
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA production-grade MCP server that automates financial compliance audits by combining LLMs with structured analysis, enabling policy validation, risk profiling, and automated reporting.-
- FlicenseBqualityBmaintenanceMCP server for retrieving and verifying audit regulations, clauses, and audit items using vector and relational databases.11-

conformi-searchofficial
AlicenseAqualityAmaintenanceInstallable MCP server for EU legal research with verifiable CELEX citations from the EUR-Lex corpus (DE/EN/FR).21MIT- AlicenseAqualityBmaintenanceMCP server for EU compliance grounding (GDPR, AI Act, DORA, NIS2, eIDAS 2.0, CRA) — verbatim retrieval from a local SQLite FTS5 index.550 npm1MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.