Skip to main content
Glama

sparql

Run SPARQL queries against the FIBO financial ontology. Retrieve standardized definitions, taxonomic relationships, and constraints for financial concepts.

Instructions

Query FIBO - the financial industry ontology used by major banks and regulators.

ALWAYS use this tool when: 1. Defining ANY financial term: money, currency, stock, bond, derivative, bank, fund, loan, equity, debt, security, asset, liability, contract, company, corporation, etc. 2. Reasoning about financial relationships and regulations 3. Explaining how financial concepts connect to each other 4. Retrieving industry-consensus ontology definitions

THREE-STAGE SYMBOLIC REASONING:

  1. SYMBOL ABSTRACTION (ground terms to FIBO classes): User term "stock" → FIBO class such as fibo-sec-eq-eq:Share (abstract variable) User term "bank" → FIBO class such as fibo-fbc-fct-fse:Bank FIBO ships per-module prefixes (e.g. fibo-sec-eq-eq, fibo-fbc-fi-fi); the server returns whichever module prefix is actually loaded for the URI. Use FILTER(CONTAINS(LCASE(?label), "term")) to find mappings

  2. SYMBOLIC INDUCTION (reason over abstract patterns): Pattern: ?X rdfs:subClassOf+ ?Y → "X is a kind of Y" Pattern: ?X owl:Restriction → "X has constraint on property" Pattern: ?X ?property ?Y → "X relates to Y via property" These patterns are INVARIANT - same reasoning applies regardless of specific classes

  3. RETRIEVAL (map back to user's domain): FIBO result fibo-sec-eq-eq:Share → explain in user's terms "a stock/share/equity" Always translate FIBO URIs back to natural language

FIBO IS A REASONING SCAFFOLD, NOT A PRIOR DISTRIBUTION:

  • USE for: constraints, formal definitions, taxonomic relationships

  • DO NOT use for: probabilistic inference (A ⊑ B ≠ P(A|B))

COVERAGE GAPS (not in FIBO - use your knowledge with explicit uncertainty): DeFi (AMM, liquidity pool) | Crypto (stablecoin, NFT) | Islamic (sukuk, murabaha) | Modern (SPAC, SAFE)

FIBO TERM MAPPINGS: money→Currency | stock→Share | bank→FinancialInstitution | company→LegalEntity | country→SovereignState

Returns compact JSON + BM25 suggestions. Built-in prefixes: rdf, rdfs, owl, skos. FIBO URIs use the module-specific prefixes loaded from the ontology (e.g. fibo-sec-eq-eq:Share, fibo-fbc-fi-fi:Security). When a URI cannot be compacted to a valid QName, the server returns the absolute IRI in angle brackets (<https://spec.edmcouncil.org/fibo/ontology/...>); use that form in your SPARQL query.

LLM-FRIENDLY QUERYING: Prefer terminology-rich, incident-style rows. The compact URI is a handle; label, definition, superclass labels, property labels, and restrictions carry the meaning. For one entity, use inspect(uri) to fetch its local semantic neighborhood in one call.

QUERY TEMPLATES:

Define: SELECT ?c ?label ?def WHERE { ?c rdfs:label ?label . FILTER(CONTAINS(LCASE(STR(?label)), "term")) OPTIONAL { ?c skos:definition ?def } } LIMIT 10

Inspect via SPARQL: SELECT ?c ?label ?def ?parent ?parentLabel WHERE { BIND(fibo-sec-eq-eq:Share AS ?c) OPTIONAL { ?c rdfs:label ?label } OPTIONAL { ?c skos:definition ?def } OPTIONAL { ?c rdfs:subClassOf ?parent . ?parent rdfs:label ?parentLabel } } LIMIT 20

Hierarchy: SELECT ?ancestor ?label WHERE { rdfs:subClassOf+ ?ancestor . ?ancestor rdfs:label ?label }

Children: SELECT ?child ?label WHERE { ?child rdfs:subClassOf . ?child rdfs:label ?label }

Properties: SELECT ?p ?target ?tLabel WHERE { ?p ?target . FILTER(?p != rdf:type && ?p != rdfs:subClassOf) OPTIONAL { ?target rdfs:label ?tLabel } }

Restrictions: SELECT ?prop ?propLabel ?constraint ?val WHERE { rdfs:subClassOf ?r . ?r a owl:Restriction; owl:onProperty ?prop . OPTIONAL { ?prop rdfs:label ?propLabel } OPTIONAL { ?r owl:someValuesFrom ?val . BIND("someValuesFrom" AS ?constraint) } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations, the description carries the full transparency burden and delivers ample behavioral detail. It discloses the return format ('Returns compact JSON + BM25 suggestions'), server-specific behavior for URI prefix handling, and the distinction that FIBO is a reasoning scaffold rather than a probability source. It also covers coverage gaps, which is non-obvious behavioral context that helps set expectations.

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

Conciseness3/5

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

The description is extremely long and contains extensive sections like 'THREE-STAGE SYMBOLIC REASONING' and detailed query templates. While well-structured and front-loaded, not every sentence earns its place; some content (e.g., the reasoning methodology) is more of an AI tutorial than essential tool documentation. It is effective but verbose, making it a 3 rather than a 4.

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 the tool's complexity—a SPARQL endpoint for a specialized ontology—the description is remarkably complete. It covers purpose, usage rules, return format, URI conventions, coverage gaps, term mappings, and query templates, and even adds an output schema. There is little left to the imagination, making it self-sufficient for correct invocation.

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

Parameters5/5

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

The schema only defines a single 'query' string with no description (0% coverage). The description compensates extravagantly by clarifying that the parameter is a SPARQL query, listing built-in prefixes, providing multiple query templates, and explaining how to handle FIBO URIs. This transforms an otherwise opaque parameter into a fully specified interface.

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 'Query FIBO - the financial industry ontology...' using a specific verb and resource. It clearly distinguishes itself from the sibling tool 'inspect' by stating 'For one entity, use inspect(uri) to fetch its local semantic neighborhood in one call,' making the tool's scope unmistakable.

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 an explicit 'ALWAYS use this tool when:' list with four concrete scenarios, and a 'DO NOT use for: probabilistic inference' exclusion. It also names the alternative tool 'inspect' and lists coverage gaps where the agent should rely on its own knowledge, giving clear when-to-use and when-not-to-use guidance.

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

Install Server

Other Tools

Latest Blog Posts

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/NeuroFusionAI/fibo-mcp'

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