RDF4J MCP Server

by odysa

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., sparql_select vs. sparql_ask vs. sparql_construct). However, describe_resource overlaps significantly with sparql_construct as both return triples, which could cause misselection.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., list_repositories, get_statistics, select_repository). The sparql_* tools use a predictable sparql_<query_type> convention, maintaining overall consistency.
Tool Count5/5
13 tools is well-scoped for an RDF4J server, covering querying, schema exploration, and repository management without feeling bloated or sparse.
Completeness4/5
The tool set provides strong coverage for querying, schema discovery, and repository selection. Minor gaps include no SPARQL UPDATE/insert/delete operations and no explicit repository creation, but these are not critical for a read-oriented RDF explorer.
Average 3.9/5 across 13 of 13 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full weight. It only says 'Get statistics,' implying a read-only operation, but does not disclose side effects, required permissions, or what format the statistics are returned in. The phrase 'and more' leaves important behavior unspecified.
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, direct sentence that immediately states what the tool does and lists key statistics covered. No fluff, no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description needs to explain the return shape or behavior. It only lists some statistics and says 'and more,' leaving the caller uncertain about what exactly is returned. The context is minimal for a potentially useful tool.
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% for the single parameter repository_id, and the description adds no additional parameter-related semantics. Baseline is 3 since the schema already fully documents the parameter.
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 identifies the tool as retrieving statistics about a repository and specifies what those statistics include (triple counts, class counts, property counts). This is a specific verb+resource pairing, but it does not explicitly distinguish itself from the sibling get_schema_summary tool, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or scenarios where get_statistics is preferred over, say, get_schema_summary or list_repositories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It partially discloses behavior by listing the content of the overview, but it does not explicitly state it's a read-only operation, any side effects, or the output format. This is a minimal disclosure.
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, well-structured sentence with no extraneous information, achieving high conciseness.
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 simple tool with one optional parameter and no output schema, the description adequately covers the main aspects of what the tool returns. However, it does not specify the exact output structure or whether a repository must be selected, which slightly limits completeness.
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 provides 100% coverage with a description for repository_id, so the tool description adds no extra parameter semantics. Baseline score of 3 is applied.
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 uses a specific verb 'Get an overview' and lists the resource contents (statistics, main classes, properties, namespaces), making the purpose clear. It does not explicitly name sibling alternatives but the aggregate nature distinguishes it implicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the sibling tools like get_statistics or get_namespaces. There are no exclusion conditions or alternative recommendations, leaving the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the return value (prefix-namespace pairs) and purpose, but does not mention behavior such as the default repository selection (though the schema does), potential error cases, or whether standard prefixes are included. This is adequate for a simple read operation but lacks edge-case 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?
The description is concise at two sentences, with no redundant information. The main action and resource are front-loaded, making it easily scannable.
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 simple one-parameter tool with no output schema, the description adequately explains the output and use context. It does not cover potential errors or behavior when no repository is selected, but given the low complexity, it is nearly complete.
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 schema description covers the only parameter (repository_id) 100%, including that it uses a default if not specified. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
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 retrieves namespace prefix mappings for a repository, with a specific purpose for SPARQL queries. It uses a specific verb ('get') and resource ('namespace prefix mappings'), distinguishing it from sibling tools that execute queries or search entities.
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 implies use before SPARQL queries to obtain prefixes, but it does not explicitly say when to use it versus other repository tools or when to specify the repository_id. No alternatives or exclusions are mentioned, leaving usage context somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds that results are JSON and represent tabular data, which is useful, but it does not explicitly state read-only semantics, error behavior, or how parameters like limit affect execution. This is only partial 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?
The description is two sentences, front-loaded with the primary action, and every word contributes value. No unnecessary information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but has no output schema, so the description should clarify the return shape. It only says 'JSON' and 'tabular data with variable bindings,' which is somewhat vague. It also omits details about limit/repository behavior, though those are in the schema, making it not fully complete.
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?
All three parameters have descriptions in the schema, so coverage is 100%. The description does not add any parameter-specific detail, relying on the schema, which warrants the baseline score.
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 'Execute a SPARQL SELECT query and return results as JSON,' clearly identifying the action and output format. It also distinguishes from sibling tools like sparql_construct and sparql_ask by specifying 'tabular data with variable bindings' and the SELECT query form.
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 'Use this for queries that return tabular data with variable bindings' provides a clear context for when to use this tool. However, it does not explicitly list alternatives or state when not to use it, falling short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format (Turtle, human-readable summary) and scope (subject and object). However, it does not explicitly state that the operation is read-only, and there's no mention of performance implications or repository selection requirements. It provides basic transparency but not comprehensive behavioral 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 a single, focused sentence that states the purpose and output format without unnecessary detail. It is front-loaded with the primary action and adds one key detail about the return type. Every word serves a purpose.
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 simple read-only tool with only one required parameter and full schema coverage, the description provides adequate context: what it does and what it returns. It lacks some contextual details like when to choose this over SPARQL construct, but given the simple interface and schema descriptions, it is reasonably complete. No output schema exists, so the description's mention of Turtle format and summary helps set expectations.
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 already provides descriptions for all three parameters, giving 100% coverage. The description adds slight semantic value by clarifying that 'all triples' includes both subject and object directions, which aligns with the include_incoming parameter. However, it does not elaborate on repository_id or include_incoming beyond the schema, so the schema carries most of the burden.
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 'Get all triples' and clearly identifies the resource by IRI. It distinguishes from sibling query tools by focusing on a single resource and specifying both subject and object direction. The output format is stated, leaving no ambiguity.
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 implies a clear use case: retrieving all triples for a known resource. However, it does not explicitly reference alternative tools like sparql_construct or state when NOT to use this tool, so it lacks explicit exclusion guidance. The context signals show many sibling tools, but the description alone does not position this tool among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It does mention the return format ('instance IRIs with labels'), which is useful, but it omits details like default limit behavior (though schema covers the limit default) and repository handling. The description is minimal but not misleading.
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, front-loading the purpose ('Find instances of a class') and adding the key return behavior. Every word earns its place; there is no redundancy or irrelevant information.
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?
The tool is simple with 3 well-described parameters and no output schema. The description covers the primary purpose and return format, which is sufficient. However, given sibling tools like search_classes, a brief note on when to prefer this over a SPARQL SELECT could enhance completeness, but it is not essential for basic usage.
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%, as each parameter (class_iri, limit, repository_id) has a clear description. The tool description adds no additional parameter semantics beyond what the schema already provides, 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 uses a specific verb ('Find') and resource ('instances of a class'), clearly distinguishing it from siblings like search_classes (which searches for classes) and sparql_* (which executes queries). It also states the output format (IRIs with labels), leaving no ambiguity about what the tool returns.
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 implies the use case: when you want instances of a specific class. However, it does not explicitly mention alternatives or when not to use it, such as against sparql_select for complex queries. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the operation is a read (get) and specifies the output (repository ID), but does not disclose whether the result could be null, how the 'current selection' is determined, or any error behavior. Still, for a simple getter, this is reasonable.
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, directly front-loaded sentence with no wasted words. It fully conveys the purpose.
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?
Given the low complexity (no parameters), the description is sufficient: it tells exactly what is returned. Absence of an output schema is mitigated because the return value is named (repository ID). It could mention possible null, but overall it is complete for a simple getter.
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 the schema is empty (100% coverage). Per the rubric, 0 params baseline is 4. The description adds no parameter details because none exist.
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 ('Get') and resource ('currently selected default repository ID'), clearly distinguishing it from siblings like list_repositories and select_repository. It unambiguously states what is returned.
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 usage is implied: it is the tool to retrieve the current default repository, as opposed to listing all repositories or changing selection. However, the description does not explicitly state when to use it over alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait of persistence ('This persists until another repository is selected'), but it does not mention potential failure modes (e.g., invalid repository ID) or return behavior. For a simple setter, this is adequate but not exhaustive.
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 short sentences, each serving a distinct purpose: stating the action and the persistence behavior. There is no wasted wording, and the most important information is front-loaded.
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?
The tool is low-complexity (1 parameter, no output schema), and the description covers what it does and its persistent effect. With no annotations, it could be more explicit about error cases, but the description is sufficiently complete for a simple setter operation.
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 a clear description for repository_id ('Repository ID to select'). The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score 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 uses a specific verb ('Select') and resource ('repository') plus the purpose ('use as the default for subsequent operations'). This clearly distinguishes it from sibling tools like list_repositories and get_current_repository.
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 implies when to use the tool: when you want to set the default repository for subsequent operations. It also provides context about persistence, but it doesn't explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool returns a boolean result and is for yes/no questions, but it does not explicitly mention read-only nature, error handling, or permission requirements. It adds some behavioral context but not comprehensive coverage.
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, immediately conveys action and purpose with no filler. Each sentence earns its place: one for function, one for use case.
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?
The description covers purpose, return type, and typical use case. Given the simple tool and full schema coverage, it is sufficiently complete, though it could briefly mention repository_id behavior or contrast with SELECT more explicitly.
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 already describes both parameters with 100% coverage, so the baseline score of 3 applies. The description adds no additional parameter semantics beyond what the schema provides.
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 'Execute a SPARQL ASK query' and specifies the output 'return a boolean result', distinguishing it from sibling SPARQL tools like sparql_select and sparql_construct. The yes/no phrasing makes the tool's specific role 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?
It explicitly says 'Use this for yes/no questions about the data', providing a clear when-to-use context. It does not explicitly contrast with alternatives, but the yes/no framing differentiates it from SELECT/CONSTRUCT queries enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses the output format (Turtle) and query forms, but does not mention potential performance implications, error behavior, or that CONSTRUCT/DESCRIBE are read-only. This is a minimal but non-misleading disclosure; no contradictions.
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 consists of two concise sentences that front-load the core function and output format, followed by a clear usage directive. Every word earns its place with no redundancy.
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 simple query tool with two parameters and no output schema, the description adequately covers purpose, output, and usage context. It lacks details on edge cases or error handling but is reasonably complete for the tool's complexity.
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 already provides 100% coverage for both parameters (query and repository_id), with clear descriptions. The main description adds no extra parameter details beyond what the schema states, so the baseline 3 applies.
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 executes SPARQL CONSTRUCT or DESCRIBE queries and returns Turtle, which precisely identifies its function. It distinguishes from siblings like sparql_select (tabular results) and sparql_ask (boolean) by specifying the output format and query 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?
The description explicitly advises using this tool 'for queries that return RDF triples/graphs,' which provides clear selection criteria. It does not name alternatives like sparql_select directly, but the guidance implies the differentiator, making it useful for an AI agent to choose appropriately.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately indicates a read-only search operation ('Find classes') and discloses the return structure (IRIs with labels and comments). It does not describe potential edge cases or exact regex behavior, but for a simple search tool it is sufficiently transparent and non-misleading.
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 extremely concise—three short sentences, each carrying distinct information: purpose, filtering, and return format. There is no fluff or repetition, and the key facts are front-loaded.
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 tool with 3 optional parameters and no output schema, the description provides the essential context: what it searches, how it can be filtered, and what it returns. It does not explain repository context or response marshalling, but these are adequately inferred from the description and sibling tools. It is nearly complete, though a 5 would require explicit details on execution context (e.g., selected repository).
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%, as every parameter (limit, pattern, repository_id) has a description. The description adds minimal value beyond the schema—just restating that filtering by name pattern is possible, which the schema already captures. Therefore, baseline 3 is appropriate per the rubric.
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 specific action ('Find classes') and resource ('the ontology'), distinguishing it from sibling tools like search_properties and find_instances. It also specifies the key capability of filtering by name pattern and the return format (IRIs with labels and comments), leaving no ambiguity about purpose.
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: it is for finding ontology classes, optionally filtered by name pattern. It does not explicitly mention alternatives or when not to use this tool, but the context is strong enough to infer its role among siblings. Lacks explicit exclusions or comparisons, so not 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?
With no annotations provided, the description carries the full burden. It discloses key behaviors: support for filtering by pattern, domain, or range and returning specific data fields. It does not mention pagination or limit behavior, but this is a minor gap for a read-only search tool.
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 that front-load the purpose and specify behavior without unnecessary verbiage. Every sentence adds value, covering the core function, available filters, and expected output.
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?
Despite having no output schema or annotations, the description adequately covers the tool's function, filters, and return structure. Minor details like limit behavior and repository context are partially covered by the schema and sibling tools, but the overall picture is sufficient for a search tool.
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 schema fully documents all five parameters (100% coverage), so the baseline is 3. The description only restates pattern, domain, and range as filters without adding new semantics or syntax beyond what the schema already provides.
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 'Find properties in the ontology' with a specific verb and resource. It also mentions filtering by pattern, domain, or range and return of property IRIs with labels, domains, and ranges, which defines scope and distinguishes it from sibling tools like search_classes and find_instances.
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 establishes clear context for finding properties, implicitly distinguishing it from sibling tools for classes and instances. However, it does not explicitly state when not to use this tool or name alternatives, so it lacks explicit exclusions.
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?
With no annotations, the description carries the full burden. It clearly states the action (list) and the return fields, which implies a safe, read-only operation. However, it does not explicitly declare that it is read-only or mention authentication requirements, but for a simple listing this is adequate.
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 short, front-loaded sentences with no wasted words. The key verb and result are stated immediately.
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 simple parameterless listing tool with no output schema, the description fully covers what the tool does and what it returns. It is complete enough for an agent to correctly invoke the tool.
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 schema coverage is 100%, so the baseline is 4. The description does not need to add parameter details, and it correctly focuses on the output.
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+resource ('List all available RDF repositories') and clearly states what the tool returns (IDs, titles, access permissions). It is easily distinguished from sibling tools like select_repository and get_current_repository.
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 usage context is implied: use this to see available repositories. However, no explicit comparisons or exclusions are given for sibling tools such as select_repository or get_current_repository, nor is there a when-not-to-use statement.
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:

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

Score Badge

Copy to your README.md:

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

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/odysa/rdf4j-mcp'

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