Skip to main content
Glama
FINOS AI Governance MCP Server

FINOS AI Governance MCP Server

Official
by finos

Search Frameworks

search_frameworks

Find an exact phrase in AI governance framework documents to locate relevant sections and passages, returning framework IDs, matched context, and occurrence counts.

Instructions

Find an exact phrase in the text of the AI governance frameworks.

Frameworks only: this tool does not search risks or mitigations. To find a risk or a mitigation, call list_risks or list_mitigations, choose from the titles and descriptions, then read it with get_risk or get_mitigation.

The query is matched as one phrase of whole words. Case is ignored, and hyphens and underscores count as spaces, so "third party" finds "third-party". Words of the query that appear apart are not a match, and neither is a word inside a longer one. Link addresses are not searched.

Returns one result per framework that says the phrase, in the order list_frameworks gives them. Results are not ranked. Each has the framework's document_id (pass it to get_framework), the section and passage around the first occurrence, and occurrences, the number of times that framework says the phrase. If nothing is found, no framework says that phrase: try a shorter phrase or a single word.

A search that could not run is an error, not an empty result. A framework that cannot be read is left out, and the search fails if none can be read.

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": {
      "query": "<query>"
    },
    "name": "search_frameworks"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of frameworks to return (1-20), taken in catalog order. At most one passage per framework. total_found counts every framework that says the phrase, including those this limit left out.
queryYesThe exact phrase to find in the framework documents. Case is ignored; hyphens and underscores count as spaces.

Output Schema

NameRequiredDescriptionDefault
queryYes
resultsYes
total_foundYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: whole-word phrase matching, case-insensitivity, hyphen/underscore normalization, no partial or sub-string matches, link addresses excluded, unranked results in list_frameworks order, and one passage per framework. It also distinguishes a failed search (an error) from an empty result and discloses that unreadable frameworks are silently omitted. The only shortfall is that it does not describe the shape of the error payload or any auth/permission requirements, so it stops just short of fully transparent.

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?

Front-loaded with purpose and scope, then matching rules, then result shape, then error behavior — a sensible order with no filler sentences. It is slightly long, and the case/hyphen normalization rules are effectively restated from the query schema, a small redundancy.

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?

An output schema exists, so return-value detail is optional, yet the description still names the key fields (document_id, section, passage, occurrences) that drive the next call to get_framework. Combined with match semantics, ordering, and failure behavior, nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description exceeds it by explaining the matching semantics of the query in more detail than the schema does, including that scattered words are not a match and that words inside longer words do not match. It also adds context for limit by noting results come in list_frameworks catalog order and that only one passage per framework is returned, which the schema states only partially.

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?

States a specific verb and resource: find an exact phrase in the text of the AI governance frameworks. It immediately scopes itself as "Frameworks only: this tool does not search risks or mitigations," which separates it from list_risks, list_mitigations and the get_* readers without requiring 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?

Gives explicit when-not guidance plus the alternative workflow: to find a risk or mitigation, call list_risks or list_mitigations, choose from titles/descriptions, then read with get_risk or get_mitigation. It also tells the agent what to do on a miss ("try a shorter phrase or a single word") rather than leaving the agent to guess.

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