@oilflow/mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.1
Disambiguation4/5
Most tools map cleanly to a distinct resource or workflow: pre-deal, KYC, regulatory matrix, cluster feed, LC, UBO, receipts, and keys. The only real ambiguity is predeal_preview vs predeal_check, which are the same core function split by API-key requirement, and cluster_check vs clusters_list, though names and descriptions differentiate lookup from browsing. Overall an agent can reliably select the right tool.
Naming Consistency4/5
The dominant pattern is domain_operation: predeal_preview, regulatory_check, cluster_check, kyc_screen, lc_validate, ubo_screen. A few tools break the pattern with verb-first names like verify_receipt and request_sandbox_key, and noun-only names like regulatory_countries, regulatory_products, clusters_list, and ubo_graph. It is not perfectly uniform, but the naming is still predictable and readable.
Tool Count5/5
13 tools is well within the ideal range for a compliance-focused API and each tool corresponds to a distinct endpoint or workflow. The set covers multiple compliance subdomains without feeling bloated, and the free/keyed pre-deal pair is intentional rather than redundant.
Completeness4/5
The major workflows are covered: pre-deal checks, receipt verification, regulatory matrix lookups, cluster intelligence, LC validation, and UBO screening with polling. A minor gap is that kyc_screen can return queued results with a poll_url but there is no dedicated MCP tool to poll KYC results, though agents can work around this via the URL.
Average 4.5/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, covering the safety profile. The description adds a valuable data-quality caveat: 'Severity 'suspected' rows are publicly reported leads, not OilFlow-confirmed,' which helps the agent interpret results correctly.
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, each earning its place: main action, use case, and a critical caveat. The primary operation is front-loaded, with no redundant wording.
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 read-only list tool with no output schema, the description covers the feed source, filter options, and severity semantics. It does not mention pagination or return-field details, but those are not essential for a correct first invocation.
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 coverage is 100%, with descriptions for all three parameters (since, country, severity). The description only restates the availability of these filters without adding format or constraint details beyond the schema.
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?
The description clearly states a specific verb and resource: 'List entries from the Scam Cluster Intelligence Feed,' and identifies optional filters. While it does not explicitly contrast with sibling tools like cluster_check, the operation is unambiguous.
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?
The phrase 'Useful for browsing known fraud clusters' provides a clear context for when to call this tool. It does not name alternatives or exclusions, but the use case is sufficiently clear for a read-only feed-browsing operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses critical behavioral traits: PEP screening is not shipped and users must be told, sanctions/registration/asset/footprint steps run out-of-band and return as 'queued' with a poll_url, and a verdict plus per-check evidence is returned. It also clarifies the tool is decision-support, not a legal determination. No contradiction with the annotations exists.
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?
The description is dense but every sentence carries necessary information: scope, critical limitation, async behavior, return shape, intended use, and prerequisite. The most important action and scope are front-loaded, and the caveats are placed where they are most actionable.
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 complex tool with no output schema, the description is remarkably complete: it names the data sources, explains the async queuing behavior and poll_url, defines the return verdict values, states the PEP limitation, sets expectations about legal authority, and notes the API key requirement. An agent has enough context to invoke it correctly and communicate results honestly.
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 schema already documents all five parameters fully. The description does not add much parameter-level meaning, but it provides useful context about what the screen does with the supplied company information. This meets the baseline for full schema coverage.
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 states an explicit action ('Run an OilFlow counterparty KYC screen') and enumerates the concrete scope: cluster-blocklist match, regulatory tradability, a 7-step registration pipeline, and 8-list sanctions screening. The resource is clearly distinguished from sibling tools like regulatory_check, cluster_check, and ubo_screen by framing it as a comprehensive KYC pipeline rather than a single-purpose check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context such as requiring a production API key, being decision-support for a compliance analyst, and not being a legal determination, and it warns that PEP screening is not included. However, it does not explicitly state when to prefer this tool over sibling alternatives like ubo_screen or regulatory_check, nor does it name any alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and idempotent. The description adds meaningful extra context: results are compiled regulatory guidance, not legal advice, and the user should confirm with a national regulator. It also discloses the non-legal nature of the matrix.
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?
Two sentences that front-load the core action and return behavior, then add a necessary caveat. No wasted words; the legal disclaimer earns its place given the domain.
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 low-complexity read-only lookup with fully documented parameters and no output schema, the description is complete: it names the inputs, the output, and the operational limitation. The agent has enough to call it correctly without further elaboration.
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. The description's supplied/bought wording loosely maps to the listing_type supply/demand distinction, but it does not add meaningful detail beyond what the schema already documents for country, product, and listing_type.
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 clearly states the tool's exact purpose: checking whether a commodity can be supplied/bought in a jurisdiction using OilFlow's regulatory matrix. It also names the return shape (allowed true/false plus blockers), which separates it from listing-oriented siblings like regulatory_countries.
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?
The description gives a clear usage context: use this when you need a tradability determination for a specific country/product combination. It does not explicitly mention when to prefer regulatory_countries or regulatory_products, but the conditions for use are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable detail beyond annotations by specifying the async status expectation ('once status is ready') and the returned graph content (nodes, edges, risk, flagged patterns).
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 tight sentences front-load the action and resource, then give the prerequisite, then describe the outcome. No filler or repetition of annotation fields.
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 tool, the description is complete: it states the prerequisite, the readiness condition, and the returned content despite lacking an output schema. An agent has enough to call and interpret the tool correctly.
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 coverage is 100%, and the schema already explains graph_id as returned by ubo_screen. The description reinforces that same relationship but does not add new format, constraints, or default information, so a baseline 3 is appropriate.
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 uses a specific verb ('Fetch') and names the exact resource: the status/result of a UBO graph build initiated by ubo_screen. It clearly distinguishes itself from the related sibling ubo_screen by focusing on retrieval rather than creation.
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?
It gives clear context: call this only after ubo_screen has returned a graph_id, and wait until status is 'ready' for the full result. It does not explicitly state when not to use it or name alternative tools, so it stops one step short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations, disclosing the 8 sanctions lists, the PEP exclusion, the OFAC 50% rule, cache-return behavior, the partial US registry coverage post-March-2025, and the interpretive warning that flagged patterns are signals rather than verdicts. This is rich behavioral context that an agent needs before invoking and before passing results to a user.
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 longer than a typical tool description, but every sentence carries useful information: caching behavior, polling path, regulatory limitations, and authentication requirements. The main action is front-loaded, with caveats placed later. It is dense but not bloated, and the length is justified by the tool's complexity.
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?
Even without an output schema, the description explains what a response contains: either a cached graph or a graph_id to poll with ubo_graph. It also provides the critical coverage caveat to relay, the production key requirement, and the risk-interpretation guardrail, making the description effectively complete for correct invocation and result handling.
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?
The input schema has 100% parameter description coverage, so the schema already documents root_entity_name, root_jurisdiction, and force_refresh. The tool description does not need to repeat parameter details and does not add much parameter-specific meaning, so the baseline of 3 is appropriate.
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 opens with the specific action 'Start a beneficial-ownership (UBO) graph traversal for an entity' and explains what that traversal does: walks registries, flags shell-company patterns, and screens for sanctions exposure. It also distinguishes itself from the sibling ubo_graph by positioning this tool as the initiator and ubo_graph as the polling target, and warns that PEP is not screened.
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?
The description gives clear usage context: use this tool to start a UBO graph, and when the cache is unavailable, poll ubo_graph with the returned graph_id. It also explains the production API key requirement and the coverage caveat to pass on. It does not explicitly contrast with kyc_screen or other sibling tools beyond the PEP exclusion, stopping short of a full when-to-use/when-not-to-use guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/openWorld/idempotent/destructive traits. The description adds meaningful behavior beyond annotations: severity semantics ('confirmed' vs. 'likely' vs. 'suspected'), the warning that 'suspected' is not first-party confirmed, and the caveat that 'matched:false' is not an exoneration. This is high-value interpretive context.
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?
The description is compact (three sentences) and front-loaded with the primary action, followed by essential output semantics and a false-negative caveat. Every clause adds information; no filler or repetition of schema details.
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?
Without an output schema, the description adequately covers return behavior: severity values, the 'matched:false' case, and the 'suspected' lead warning. It also implies cited sources exist. For a simple two-parameter lookup, this is complete enough for an agent to call and interpret results correctly.
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. The description doesn't add parameter-level details beyond the schema — entity and country are already clearly described in the schema. No meaningful extra parameter semantics are provided.
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 uses a specific verb ('Look up') and names a precise resource ('OilFlow's first-party-investigated Scam Cluster Intelligence Feed'). It also explains the output severity scale and the meaning of 'matched:false', which clearly scopes this tool as a scam-cluster name lookup, distinct from siblings like kyc_screen or regulatory_check.
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?
The description gives a clear context: checking counterparty names against a specialized fraud feed. However it does not explicitly name sibling tools or specify when not to use it. Still, the context strongly implies its niche vs. other screen types, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnly, idempotent, and non-destructive behavior, and the description adds meaningful behavioral context beyond them: it discloses the sandbox 403 failure mode, defines the output shape (discrepancies with severity, honor/inquiry/refuse recommendation, cited UCP 600 articles), and explicitly limits the output to draft decision-support rather than a legal opinion. This is substantial supplementary transparency.
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 with no filler: the first states the core action and inputs, the second summarizes outputs, and the third conveys authentication constraints and an important limitation. Everything earns its place and the most critical information is front-loaded.
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?
Given there is no output schema, the description appropriately explains what the tool returns: discrepancies with severity, an overall recommendation, and the UCP 600 articles cited. It also covers the authentication requirement and the non-legal nature of the output. An agent has enough context to invoke the tool correctly and interpret its result.
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 parameter objects are already documented in the schema. The description adds only that the three objects together form the presentation being validated, which is helpful framing but does not provide additional per-parameter meaning beyond what the schema already contains. Baseline 3 is appropriate.
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 uses a specific verb ('Validate') and clearly names the resource and scope: a Letter of Credit presentation consisting of LC, invoice, and bill of lading, checked against UCP 600 rules. It is immediately distinguishable from the unrelated sibling tools in this toolset.
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?
The description clearly establishes the context in which this tool is used — validating a documentary-credit presentation under UCP 600 — and provides an important prerequisite: a production API key is required and sandbox keys will fail with 403. It does not explicitly name alternatives or exclusions, but no sibling tool competes for this use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destrructiveHint=false, so the safety profile is covered. The description adds value by specifying that the result includes a count and the country list, plus the exact jurisdiction count of 235. No hidden side effects or auth concerns are relevant for this read-only listing operation.
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?
The description is two concise sentences with no filler. It front-loads the core purpose, includes the key count, and ends with the actionable downstream use, making it easy to process quickly.
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 zero-parameter, no-output-schema listing tool, the description covers the essential facts: what is listed, how many items, what the items include, and how to use the result. There is no meaningful missing context.
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?
The tool has zero parameters and an empty input schema with 100% schema description coverage, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because no parameter guidance is needed.
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 uses a specific verb ('List') and a precise resource ('jurisdictions covered by the OilFlow regulatory matrix'), and it states the exact output (a count and country list with slugs). This clearly separates it from sibling tools like regulatory_check and regulatory_products.
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?
The description provides clear context by noting that the returned slugs are 'for use in regulatory_check,' helping an agent understand when to invoke this tool first. It does not explicitly discuss when not to use this tool or compare it with alternatives like regulatory_products, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context by noting the result is a canonical, recognized set of categories rather than arbitrary or free-form values, which helps the agent understand the closed vocabulary. This goes beyond what the annotations alone provide.
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?
The description is a single, focused sentence with no filler. It front-loads the action and resource, then adds the purpose clause, making it easy to parse quickly.
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 zero-parameter, read-only list tool without an output schema, the description is complete. It states what is returned, the nature of the data (canonical labels), and the downstream use case, which is all an agent needs to select and invoke the tool correctly.
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?
There are zero parameters, so the baseline of 4 applies. The description adds meaning by clarifying that the returned categories are meant to be used as the `product` argument to regulatory_check, providing relevant semantic linkage even without parameters.
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 uses a specific verb ('List') and identifies a clear resource: commodity/product categories recognized by the regulatory matrix. It also explains the purpose — supplying the `product` argument to regulatory_check — which distinguishes it from sibling tools like regulatory_countries and regulatory_check itself.
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?
The description explicitly tells the agent when to use this tool: to obtain canonical labels for the `product` argument in regulatory_check. It does not discuss when not to use it or name alternatives, but the intended use case is clear and sufficient for a zero-parameter list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and non-destructive behavior, and the description adds substantial context beyond that: no API key required, the returned signature enables independent audit, receipt_type semantics for sanctions_screen vs predeal_verdict, and the practical limitation that sanctions-only coverage does not flag PEPs who are not also designated. This is genuinely 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?
The description is long but every sentence contributes: purpose, auth requirement, return contents, semantic meaning of receipt_type, the PEP limitation, and the triggering user context. It is front-loaded with the core purpose and keeps the most operationally important detail ('NO API KEY REQUIRED') near the start.
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 tool with no output schema, the description covers the input origin, return shape, key field semantics, trust implications, and the user-facing caveat about coverage. Nothing essential is missing for an agent to select and call this tool correctly.
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?
The schema fully documents receipt_id with 100% coverage, so the baseline is 3. The description adds value by telling the agent where receipt_id comes from: the receipt_id or verify_url field on a verdict, or from a receipt the user was handed. That helps the agent find the actual value to pass.
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 opens with a specific verb and resource: 'Independently verify an OilFlow screening receipt.' It clearly distinguishes this from the sibling screening tools by explaining that it verifies receipts rather than performing new screening checks, and it describes the concrete outputs (receipt, canonical payload string, HMAC-SHA256 signature).
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?
The description gives an explicit use case: use this whenever a user has been handed a compliance receipt and wants to know whether it is genuine and what it covered. It does not explicitly name alternatives or state when not to use it, but the context is clear enough that an agent could route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal, so the description carries the behavioral burden, and it does so thoroughly. It discloses the deterministic fallback behavior (verdict_source = 'rule_based'), the evidence-gap mechanism, the production API key requirement, the decision-support nature rather than actual clearance, the disclaimer, and the primitives run. All this is beyond what annotations alone provide.
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?
The description is dense but every sentence earns its place: outputs, primitives, reliability self-description, caveats, API-key requirement, and the preview alternative. It is front-loaded with the primary purpose and output contract in the first sentence.
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?
With no output schema, the description must explain return values, and it does: probability, verdict tier, blockers, restructure suggestion, post-restructure clearance, verdict_source, and evidence_gaps. It also covers authentication, disclaimers, fallback behavior, and the sibling alternative, making the tool fully callable by an agent without additional inference.
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 schema already fully documents all 8 parameters. The description adds useful domain context (physical-commodity deal, front-office originator) but no parameter-specific semantics beyond the schema, matching the baseline of 3.
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 states a specific verb and resource ('Run a Pre-Deal Compliance Copilot check') and enumerates the exact outputs: clearance probability, verdict tier, blockers, restructure suggestion, and post-restructure clearance. It also distinguishes itself from siblings by naming the sub-tools it orchestrates (cluster, regulatory, adverse-media, sanctions, verified-profile) and by contrasting with predeal_preview.
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 description provides explicit when-to-use guidance ('for a front-office originator'), an explicit alternative ('use predeal_preview for a free verdict without one'), and a clear exclusion ('not a clearance itself and not legal advice'). It also gives user-facing handling instructions for verdict_source and evidence_gaps, which goes beyond typical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important external side effects: the key is emailed, the email may receive follow-ups, rate limits (3 keys/IP/hour, 5 per email/day), scope exclusions, and the need to set OILFLOW_API_KEY and restart after receipt. This adds substantial context beyond the annotations and does not contradict them.
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 longer than average but densely packed with essential operational details and front-loaded with the core purpose. Some repetition exists around consent and email usage, slightly preventing a top score.
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 tool with three parameters and no output schema, the description covers the full workflow: prerequisites, consent, calling conditions, scope limits, alternatives, rate limits, and post-call setup. Nothing an agent needs to safely invoke this tool 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 description coverage is 100%, so the baseline is 3. The description adds extra semantic weight to the email parameter via strong consent requirements and the explicit warning not to supply an address the user did not request, which goes beyond the schema's brief description.
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 uses a specific verb ('Mint') and names the exact resource: a free 30-day OilFlow sandbox API key scoped to regulatory matrix and cluster endpoints. It clearly differentiates from siblings by stating which endpoint families are not covered and directing to predeal_preview for free verdicts.
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?
Explicit when-to-use guidance: this is how a keyless agent gets its user onto keyed tools. It also states when not to use it via alternatives (predeal_preview for free verdict, production pricing URL) and imposes consent and rate-limit conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by disclosing the 5-per-24-hour quota, the exact error code on exhaustion, the two verdict_source modes and why the agent should relay evidence_gaps, and the fact that the response carries a legal disclaimer that must be passed on. It also clarifies that this is decision-support, not a clearance or legal advice. Annotations are consistent with this mutating-but-not-destructive profile, so no contradiction exists.
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?
The description is long but every sentence carries operational value: main result first, then quota semantics, then output fields the agent must relay, then required-input handling, then the alternative. There is no filler or repetition of schema content. Given that no output schema exists, this density is justified and well-organized.
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 tool with no output schema and six parameters, the description covers all critical context an agent needs: what the verdict contains, how quota errors manifest, what fields to relay to the user, which inputs are mandatory, and which sibling tool to use for the higher-tier version. Nothing essential for correct invocation 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 already 100%, so the baseline is 3. The description adds meaningful semantic context beyond the schema: it enumerates the required inputs, explains that counterparty_role has no safe default because the verdict differs by side, and warns that the endpoint rejects calls missing required fields. This is a genuine supplement to the schema rather than mere repetition.
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 the specific operation (OilFlow Pre-Deal Compliance check) and the exact outputs (probability 0-100, verdict tier, blockers, restructure suggestion, receipt_id, verify_url, verdict_source, evidence_gaps). It also differentiates itself from the sibling predeal_check by explicitly labeling this the free, quota-limited version. An agent can immediately tell what this tool does and how it differs from nearby tools.
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 description gives explicit when-to-use guidance: use this for the free quota-limited verdict, and names the alternative predeal_check for the keyed version with no daily cap and full input set. It also instructs the agent to ask the user for missing required inputs rather than guessing, and clarifies that the demo_limit_reached error means quota exhaustion, not an outage. This leaves no ambiguity about when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![oilflow-mcp-server MCP server](https://glama.ai/mcp/servers/rafaemush/oilflow-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/rafaemush/oilflow-mcp-server)

Score Badge

Copy to your README.md:

[![oilflow-mcp-server MCP server](https://glama.ai/mcp/servers/rafaemush/oilflow-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/rafaemush/oilflow-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rafaemush/oilflow-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server