What can you do with this server?

The skosmos-mcp server provides an MCP interface for AI assistants to browse, search, and traverse SKOS vocabularies via the Skosmos REST API. Vocabulary Management * list_vocabularies: List all available vocabularies, optionally filtered by language. * get_vocabulary: Retrieve metadata and top concepts for a specific vocabulary. Concept Lookup * get_concept: Full concept details including broader, narrower, and related concepts. * get_concept_label / labels: All labels (prefLabel, altLabel, hiddenLabel) for a concept URI. * concept_path: Hierarchy path from a concept up to its root. Search & Discovery * search_concepts: Full-text search across one or all vocabularies, with wildcard, pagination, and language filtering support. * autocomplete: Prefix-based concept label suggestions. * resolve_label: Map a plain-text label back to matching concept URIs. Hierarchical & Graph Traversal * broader_concepts, narrower_concepts, related_concepts: BFS traversal up, down, or across concept relationships with configurable depth. * traverse_concepts: Mixed BFS traversal combining any combination of broader, narrower, and/or related relationships in one query. * All traversal tools include cycle detection and duplicate elimination. Additional Capabilities * Multi-instance support: All tools accept an optional server_url parameter (when SKOSMOS_TOOL_SERVER_URL_ALLOWED=true) to query different Skosmos instances in the same session. * Performance: In-memory caching with configurable TTL, retry logic with exponential backoff, and HTTP timeouts. * Deployment: Supports stdio (local) or HTTP server (remote/web) modes. * Resources: Direct URI-based access via skosmos://vocabularies, skosmos://{vocid}, and skosmos://{vocid}/{encodedUri}.

How do I use skosmos-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@skosmos-mcp search for 'climate' in the yso vocabulary" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

skosmos-mcp

by jsilvanus

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Hybrid

skosmos-mcp

A production-quality Model Context Protocol (MCP) server that wraps the Skosmos REST API, enabling AI assistants to navigate and query SKOS vocabularies. Also includes SPARQL query capabilities for direct RDF data access.

Features

17 MCP tools covering vocabulary browsing, concept lookup, full-text search, label resolution, BFS traversal, and schema-guided assistance
4 SPARQL tools for direct SPARQL query execution, updates, graph discovery, and query templates
3 MCP resources for direct URI-based access to vocabularies and concepts
BFS traversal engine with configurable depth cap, cycle detection, and duplicate elimination
TTL-based in-memory cache to avoid redundant API calls
Retry logic with exponential backoff for 5xx and network errors
AbortController timeout on every HTTP request
Strict TypeScript (strict mode, noUncheckedIndexedAccess, exactOptionalPropertyTypes)
Zod-validated inputs on all tools
stdio transport — reads from stdin, writes to stdout; all logging goes to stderr
StreamableHTTP transport — HTTP server at /mcp for remote or web-based MCP clients

Related MCP server: skill4agent MCP Server

Installation

npm install
npm run build

Or run directly with tsx:

npm run dev

Docker / Docker Compose

Build and run the Streamable HTTP MCP server in a container:

docker compose up --build -d

This starts the Streamable HTTP MCP server on port 3000 and uses Docker Compose's restart: unless-stopped policy so it will come back up automatically after crashes. The image defaults to the Finto endpoints, runs the HTTP MCP server on 0.0.0.0:3000, and enables alternate Skosmos/SPARQL connections by default. The container logs a warning at startup when those options are enabled because allowing other endpoints can be a security risk. The container reads the same environment variables as the local app, so copy .env.example to .env if you want to override those defaults.

Container Images from GitHub Container Registry

Releases publish two container image variants to GitHub Container Registry (GHCR):

HTTP variant (for remote access via HTTP):

docker pull ghcr.io/jsilvanus/skosmos-mcp:http
docker pull ghcr.io/jsilvanus/skosmos-mcp:http-latest
# Or use a specific release version:
docker pull ghcr.io/jsilvanus/skosmos-mcp:v0.2.1-http

Stdio variant (for local stdio MCP protocol):

docker pull ghcr.io/jsilvanus/skosmos-mcp:stdio
docker pull ghcr.io/jsilvanus/skosmos-mcp:stdio-latest
# Or use a specific release version:
docker pull ghcr.io/jsilvanus/skosmos-mcp:v0.2.1-stdio

Each release publishes both variants automatically. Choose the one that matches your use case:

HTTP variant: Runs an HTTP server on port 3000, suitable for remote access or web-based MCP clients
Stdio variant: Uses stdin/stdout for the MCP protocol, suitable for local integration with AI assistants or other MCP clients

Configuration

Copy .env.example to .env and fill in values:

SKOSMOS_BASE_URL=https://api.finto.fi    # required
SKOSMOS_DEFAULT_VOCABULARY=                      # optional
SKOSMOS_DEFAULT_LANGUAGE=en
SKOSMOS_TIMEOUT=30000
SKOSMOS_USER_AGENT=skosmos-mcp/0.2.0
SKOSMOS_CACHE_TTL=300
SKOSMOS_MAX_TRAVERSAL_DEPTH=5
SKOSMOS_TOOL_SERVER_URL_ALLOWED=true

# SPARQL Configuration (optional)
SPARQL_ENDPOINT_URL=https://api.finto.fi/sparql
SPARQL_USERNAME=
SPARQL_PASSWORD=
SPARQL_ALLOW_OTHER_ENDPOINTS=true

Variable	Default	Description
`SKOSMOS_BASE_URL`	(required)	Base URL of the Skosmos instance
`SKOSMOS_DEFAULT_VOCABULARY`	—	Default vocabulary id when not specified in a tool call
`SKOSMOS_DEFAULT_LANGUAGE`	`en`	Default language code for labels
`SKOSMOS_TIMEOUT`	`30000`	HTTP request timeout in milliseconds
`SKOSMOS_USER_AGENT`	`skosmos-mcp/0.1.0`	User-Agent header sent with API requests
`SKOSMOS_CACHE_TTL`	`300`	Cache entry TTL in seconds
`SKOSMOS_MAX_TRAVERSAL_DEPTH`	`3`	Hard cap on BFS traversal depth
`SKOSMOS_TOOL_SERVER_URL_ALLOWED`	`false`	When `true`, allows tools to accept optional `server_url` parameter to call a different Skosmos instance
`LOG_LEVEL`	`info`	Log level: debug, info, warn, error (written to stderr)
`MCP_HTTP_PORT`	`3000`	TCP port for the StreamableHTTP server
`MCP_HTTP_HOST`	`127.0.0.1`	Bind address for the StreamableHTTP server
`SPARQL_ENDPOINT_URL`	—	SPARQL endpoint URL (optional; enables SPARQL tools)
`SPARQL_USERNAME`	—	Username for SPARQL endpoint HTTP Basic auth (optional)
`SPARQL_PASSWORD`	—	Password for SPARQL endpoint HTTP Basic auth (optional)
`SPARQL_ALLOW_OTHER_ENDPOINTS`	`false`	When `true`, allows SPARQL tools to accept optional `endpoint` parameter to query a different SPARQL endpoint

MCP Tools Reference

Vocabulary Tools

`list_vocabularies`

List all available vocabularies.

Parameter	Type	Required	Description
`lang`	string	no	Language code for labels

`get_vocabulary`

Get vocabulary metadata and top concepts.

Parameter	Type	Required	Description
`id`	string	yes	Vocabulary identifier (e.g. `"yso"`)
`lang`	string	no	Language code

Concept Tools

`get_concept`

Fetch full concept details: labels, broader, narrower, related.

Parameter	Type	Required	Description
`uri`	URL	yes	Concept URI
`vocabulary`	string	no	Vocabulary identifier (required if no default set)
`lang`	string	no	Language code

`get_concept_label`

Get all labels for a concept URI.

Parameter	Type	Required	Description
`uri`	URL	yes	Concept URI
`vocabulary`	string	yes	Vocabulary identifier
`lang`	string	no	Language code

`concept_path`

Get the hierarchy path from a concept to its root.

Parameter	Type	Required	Description
`uri`	URL	yes	Concept URI
`vocabulary`	string	yes	Vocabulary identifier
`lang`	string	no	Language code

Search Tools

`search_concepts`

Full-text search across one or all vocabularies.

Parameter	Type	Required	Description
`query`	string	yes	Search string (supports trailing `*` wildcard)
`vocabulary`	string	no	Limit to this vocabulary
`lang`	string	no	Language code
`maxhits`	integer	no	Max results
`offset`	integer	no	Pagination offset

`autocomplete`

Autocomplete concept labels by prefix.

Parameter	Type	Required	Description
`prefix`	string	yes	Label prefix
`vocabulary`	string	no	Limit to this vocabulary
`lang`	string	no	Language code
`maxhits`	integer	no	Max suggestions

`resolve_label`

Resolve a label text to concept URIs.

Parameter	Type	Required	Description
`text`	string	yes	Label text to resolve
`vocabulary`	string	yes	Vocabulary identifier
`lang`	string	no	Language code

Labels Tool

`labels`

Get all labels (prefLabel, altLabel, hiddenLabel) for a concept URI.

Parameter	Type	Required	Description
`uri`	URL	yes	Concept URI
`vocabulary`	string	yes	Vocabulary identifier
`lang`	string	no	Language code

Traversal Tools

All traversal tools use BFS with cycle detection. Depth is capped at Math.min(depth, SKOSMOS_MAX_TRAVERSAL_DEPTH).

`broader_concepts`

Traverse broader (parent) concepts.

Parameter	Type	Required	Description
`uri`	URL	yes	Starting concept URI
`vocabulary`	string	yes	Vocabulary identifier
`depth`	integer	no	Max traversal depth
`lang`	string	no	Language code

`narrower_concepts`

Traverse narrower (child) concepts.

Parameter	Type	Required	Description
`uri`	URL	yes	Starting concept URI
`vocabulary`	string	yes	Vocabulary identifier
`depth`	integer	no	Max traversal depth
`lang`	string	no	Language code

`related_concepts`

Traverse related concepts.

Parameter	Type	Required	Description
`uri`	URL	yes	Starting concept URI
`vocabulary`	string	yes	Vocabulary identifier
`depth`	integer	no	Max traversal depth
`lang`	string	no	Language code

`traverse_concepts`

BFS using a mix of relationship types.

Parameter	Type	Required	Description
`uri`	URL	yes	Starting concept URI
`vocabulary`	string	yes	Vocabulary identifier
`relationships`	array	yes	One or more of: `"broader"`, `"narrower"`, `"related"`
`depth`	integer	no	Max traversal depth
`lang`	string	no	Language code

Assistance Tools

`vocabulary_schema_overview`

Summarize a vocabulary's structure with top concepts, relationship hints, and suggested tasks for AI clients.

Parameter	Type	Required	Description
`id`	string	yes	Vocabulary identifier
`lang`	string	no	Language code
`includeTopConcepts`	boolean	no	Whether to include a top concept preview
`maxTopConcepts`	integer	no	Maximum number of top concept previews

`query_guidance`

Return task-oriented guidance for common SKOS vocabulary workflows such as exploration, hierarchy traversal, or label resolution.

Parameter	Type	Required	Description
`vocabulary`	string	yes	Vocabulary identifier
`task`	string	no	One of `explore`, `resolve`, `hierarchy`, `related`, `search`, or `all`

`reconcile_concept`

Resolve a label to one or more candidate concepts using Skosmos lookup and search.

Parameter	Type	Required	Description
`text`	string	yes	Label text to resolve
`vocabulary`	string	yes	Vocabulary identifier
`lang`	string	no	Language code
`type`	string	no	Optional concept type filter
`maxhits`	integer	no	Maximum number of matches

`suggest_sparql_templates`

Return SKOS-oriented SPARQL templates for exploration, hierarchy tracing, labels, and related concepts.

Parameter	Type	Required	Description
`vocabulary`	string	no	Optional vocabulary identifier to include in the response
`task`	string	no	One of `explore`, `hierarchy`, `labels`, `related`, or `all`

SPARQL Tools

SPARQL tools enable direct querying of RDF data. Set SPARQL_ENDPOINT_URL environment variable to enable these tools. Supports both SPARQL 1.1 Query and Update protocols, with optional HTTP Basic authentication.

See the Attribution section for licensing details about the SPARQL implementation.

`execute_sparql_query`

Execute a SPARQL query (SELECT, CONSTRUCT, ASK, DESCRIBE) against the configured endpoint.

Parameter	Type	Required	Description
`query`	string	yes	The SPARQL query to execute
`endpoint`	URL	no	Optional custom SPARQL endpoint (overrides default)

Example Query:

PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?concept ?label
WHERE {
  ?concept a skos:Concept ;
           skos:prefLabel ?label .
}
LIMIT 10

`execute_sparql_update`

Execute a SPARQL update query (INSERT, DELETE, etc.) against the configured endpoint.

Parameter	Type	Required	Description
`update`	string	yes	The SPARQL update query to execute
`endpoint`	URL	no	Optional custom SPARQL endpoint (overrides default)

Example Update:

PREFIX ex: <http://example.org/>
INSERT DATA {
  ex:subject1 ex:predicate1 "object1" .
}

`list_sparql_graphs`

List all available named graphs in the SPARQL endpoint.

Parameter	Type	Required	Description
`endpoint`	URL	no	Optional custom SPARQL endpoint (overrides default)

Returns: JSON array of graph URIs.

`sparql_query_templates`

Get pre-built SPARQL query templates for common data exploration patterns.

Parameter	Type	Required	Description
`category`	string	yes	Template category: `exploration`, `property-paths`, `statistics`, `validation`, `schema`, or `all`

Categories:

exploration — Basic data discovery and statistics
property-paths — Complex graph navigation using SPARQL property paths
statistics — Knowledge graph metrics and analysis
validation — Data quality and consistency checks
schema — Structure discovery and ontology exploration

MCP Resources

URI Pattern	Description
`skosmos://vocabularies`	JSON list of all vocabularies
`skosmos://{vocid}`	Vocabulary metadata for `{vocid}`
`skosmos://{vocid}/{encodedUri}`	Concept data (labels, broader, narrower, related)

Traversal Examples

Get all ancestors of a concept (depth 3)

{
  "tool": "broader_concepts",
  "args": {
    "uri": "http://www.yso.fi/onto/yso/p8966",
    "vocabulary": "yso",
    "depth": 3,
    "lang": "en"
  }
}

Response includes nodes (with depth), edges (directed relationships), rootUri, and maxDepth.

{
  "tool": "traverse_concepts",
  "args": {
    "uri": "http://www.yso.fi/onto/yso/p8966",
    "vocabulary": "yso",
    "relationships": ["broader", "related"],
    "depth": 2
  }
}

Using Optional Server URL Parameter

All 13 MCP tools support an optional server_url parameter. When SKOSMOS_TOOL_SERVER_URL_ALLOWED=true is set in the environment, you can pass a server_url parameter to any tool to make it query a different Skosmos instance instead of the configured SKOSMOS_BASE_URL.

Example: Query a different Skosmos instance

{
  "tool": "get_concept",
  "args": {
    "uri": "http://www.yso.fi/onto/yso/p8966",
    "vocabulary": "yso",
    "lang": "en",
    "server_url": "https://alternative-skosmos.example.org"
  }
}

This allows a single MCP session to interact with multiple Skosmos instances. The server_url parameter is:

Optional on all tools
Ignored unless SKOSMOS_TOOL_SERVER_URL_ALLOWED=true (default: false)
Can be any valid URL pointing to a Skosmos instance with a compatible REST API

Why use this feature?

Query multiple Skosmos instances in parallel within a single session
Test against different Skosmos servers without restarting the MCP
Support scenarios where vocabularies are distributed across multiple instances

stdio (standard MCP deployment)

SKOSMOS_BASE_URL=https://skosmos.example.org node dist/index.js

StreamableHTTP

SKOSMOS_BASE_URL=https://skosmos.example.org MCP_HTTP_PORT=3000 node dist/http.js

The server listens on http://<MCP_HTTP_HOST>:<MCP_HTTP_PORT>/mcp (default: http://127.0.0.1:3000/mcp). Each POST request is handled as a stateless MCP session (no session ID). The SkosmosClient and CacheManager instances are shared across requests for the lifetime of the process.

Claude Desktop (`claude_desktop_config.json`)

{
  "mcpServers": {
    "skosmos": {
      "command": "node",
      "args": ["/path/to/skosmos-mcp/dist/index.js"],
      "env": {
        "SKOSMOS_BASE_URL": "https://skosmos.example.org",
        "SKOSMOS_DEFAULT_LANGUAGE": "en"
      }
    }
  }
}

Development

npm run dev          # run with tsx (no build)
npm run typecheck    # check types without emitting
npm run test         # run tests
npm run test:watch   # watch mode
npm run build        # compile to dist/
npm run lint         # lint src/ and tests/

Architecture

MCP Client (AI Assistant)
       │ stdio (JSON-RPC)
       ▼
 McpServer (SDK)
  ├── 17 Tools (Zod-validated)
  └── 3 Resources
       │
  ┌────┴────┐
  │         │
TraversalEngine   CacheManager
(BFS + cycle     (TTL, per-type)
 detection)
       │
  SkosmosClient
  (fetch + retry
   + timeout)
       │
  Skosmos REST API

Key Design Decisions

No global mutable state: config, client, cache, and traversal engine are created once in src/index.ts and passed via dependency injection.
BFS traversal: uses a queue (not recursion) to ensure breadth-first ordering and avoid stack overflows.
Depth capping: Math.min(requestedDepth, config.maxTraversalDepth) is applied in both the traversal engine and tool handlers.
Cache keys include all relevant parameters: vocabulary:${vocid}:${lang}, label:${vocab}:${uri}:${lang}, etc.
All logging to stderr — stdout is reserved exclusively for MCP JSON-RPC.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Attribution

SPARQL functionality in this project is derived from ramuzes/mcp-jena and is used under the MIT License.

Available Tools

13 tools

autocompleteB

Autocomplete concept labels by prefix

ParametersJSON Schema

Name	Required	Description
`lang`	No	Language code
`prefix`	Yes	Label prefix to complete
`maxhits`	No	Maximum number of suggestions
`vocabulary`	No	Limit to this vocabulary

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic operation, omitting important details such as whether the tool is read-only, the format of suggestions, or any side effects. The autocomplete nature implies a read operation, but this is not explicit.

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-formed sentence that conveys the core purpose with no unnecessary words. It is ideally concise.

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?

Given the absence of an output schema, the description should provide some indication of what the tool returns (e.g., list of suggestions). It fails to do so, leaving a gap in contextual completeness for a tool with 4 parameters and no output specification.

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 input schema already describes each parameter sufficiently. The description adds no additional context or examples, meeting the baseline expectation.

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 action ('autocomplete'), the resource ('concept labels'), and the method ('by prefix'), making the purpose immediately understandable. It precisely matches the tool's name.

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 sibling tools like 'search_concepts' or 'resolve_label'. There is no mention of context, prerequisites, or exclusions.

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

broader_conceptsA

BFS traversal of broader (parent) concepts up to a specified depth

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	Starting concept URI
`lang`	No	Language code
`depth`	No	Maximum traversal depth
`vocabulary`	Yes	Vocabulary identifier

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It reveals the use of BFS algorithm and depth limit, but omits performance traits, edge case behavior (e.g., missing concepts, circular references), or result format.

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 sentence of 10 words, zero waste, and front-loads the core information: algorithm, relationship, and depth constraint. Every word is meaningful.

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 tool complexity (graph traversal) and good schema coverage, the description is adequate for core functionality. However, it lacks details on return format (e.g., list of URIs, labels) or error conditions, which could be added without being excessive. No output schema exists to compensate.

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%, so the schema already documents all parameters. The description adds no additional meaning beyond the overall purpose; it does not clarify parameter relationships or constraints beyond what is in the schema.

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 performs BFS traversal of broader (parent) concepts up to a specified depth, with specific verb ('traversal'), resource ('broader concepts'), and scope ('up to a specified depth'). This distinguishes it from siblings like 'narrower_concepts' and 'related_concepts'.

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 the tool is used for hierarchical parent traversal but does not explicitly state when to use it over alternatives (e.g., 'traverse_concepts' for general traversal, 'narrower_concepts' for children). No scenarios or exclusions are provided.

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

concept_pathA

Get the hierarchy path from a concept to its root via broader transitive relations

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	Concept URI
`lang`	No	Language code
`vocabulary`	Yes	Vocabulary identifier

TDQS

A3.7/5.0

Behavior3/5

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

Without annotations, the description must disclose behaviors. It mentions 'via broader transitive relations' indicating upward traversal, but does not specify edge cases (e.g., no broader concepts), return format, or potential errors.

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, concise, front-loaded sentence with no wasted words.

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?

With no output schema, the description should clarify the return value (e.g., list of URIs or labels). It only mentions 'hierarchy path', leaving format ambiguous. Parameters are well-covered but no context on ordering or defaults.

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?

Input schema covers 100% of parameters with descriptions. The tool description adds no extra meaning beyond the schema, so 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 clearly specifies the action: 'Get the hierarchy path from a concept to its root via broader transitive relations'. It distinguishes from siblings like 'broader_concepts' (which likely returns immediate broader concepts) by emphasizing the transitive path to root.

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 when to use this tool (to get the full hierarchy path), but does not explicitly state when not to use it or mention alternatives among the siblings like 'broader_concepts' for immediate parents.

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

get_conceptC

Get full concept details including broader, narrower, and related concepts

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	Concept URI
`lang`	No	Language code for labels
`vocabulary`	No	Vocabulary identifier

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only hints at output content but lacks details on read-only nature, authorization, performance, or side effects.

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?

Single sentence with clear verb and resource. Efficiently conveys core purpose without superfluous text.

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?

Given no output schema and multiple sibling tools, description lacks detail on response structure and does not help agent decide when to prefer this aggregated tool over specific relationship tools.

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 parameters. Description does not add meaning beyond schema, so baseline score of 3 is appropriate.

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?

Description clearly states the tool retrieves concept details including relationships. It distinguishes from siblings by implying aggregation, but does not explicitly differentiate from narrower, broader, related concepts tools.

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 on when to use this tool vs siblings like broader_concepts, narrower_concepts, etc. The description is purely descriptive and does not provide selection criteria.

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

get_concept_labelB

Get all labels (prefLabel, altLabel, hiddenLabel) for a concept URI

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	Concept URI
`lang`	No	Language code
`vocabulary`	Yes	Vocabulary identifier

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. States operation is read-only ('Get'), but omits details about returned format, error handling, required permissions, or behavior for missing URIs.

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?

Single sentence, front-loaded with key information, no redundant or superfluous content.

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?

No output schema and rich sibling set (12 tools). Description does not specify return format (e.g., object or array) or handle edge cases (e.g., missing language code), leaving significant gaps for an AI agent.

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 3 parameters. Description adds minimal context beyond schema (e.g., 'for a concept URI' aligns with 'uri' param), but does not enrich understanding of 'lang' or 'vocabulary' usage.

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 identifies the verb 'Get' and the resource 'all labels (prefLabel, altLabel, hiddenLabel) for a concept URI'. It distinguishes from siblings like 'get_concept' (gets concept object) and 'resolve_label' (resolves label to concept).

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 usage when needing labels for a concept URI, but does not provide explicit when-to-use/when-not-to-use guidance or differentiate from 12 sibling tools like 'labels' or 'get_concept'.

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

get_vocabularyC

Get details of a specific vocabulary including top concepts

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Vocabulary identifier (e.g. "stw", "yso")
`lang`	No	Language code for labels

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It mentions 'including top concepts' but does not disclose whether the tool is read-only, required permissions, or any side effects. Minimal 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.

Conciseness4/5

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

The description is a single concise sentence that communicates the core function without waste, though it could benefit from slightly more detail without losing conciseness.

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?

Lacking output schema and annotations, the description should provide more context on return format, error handling, or usage scenarios. It mentions 'top concepts' but is otherwise incomplete.

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%, so the schema already describes both parameters. The description adds no additional meaning beyond what is in the schema, earning the baseline score.

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 it gets details of a specific vocabulary including top concepts, distinguishing it from siblings like list_vocabularies and get_concept, but 'details' is somewhat vague.

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 on when to use this tool versus alternatives, such as list_vocabularies for listing all vocabularies or get_concept for a specific concept. The description does not provide exclusions or context.

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

labelsA

Get all labels for a concept URI in a vocabulary

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	Concept URI
`lang`	No	Language code
`vocabulary`	Yes	Vocabulary identifier

TDQS

A4.2/5.0

Behavior4/5

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

No annotations exist, but the description clearly indicates a read-only operation ('Get') with no side effects. It does not contradict annotations, and the behavior is transparent for a retrieval 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?

A single, front-loaded sentence with no filler words. Every word is necessary and contributes to understanding the tool's 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 retrieval tool with 3 well-documented parameters and no output schema, the description is adequate. It could optionally mention the return format, but this is not critical given the clarity of the operation.

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

Parameters4/5

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

Schema coverage is 100%, providing baseline of 3. The description adds meaning by explicitly linking 'uri' and 'vocabulary' as context, which goes beyond the schema's individual parameter descriptions.

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 'labels' with context 'for a concept URI in a vocabulary', clearly distinguishing it from sibling tools like 'get_concept_label' which likely returns a single label.

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 when to use (retrieve labels for a concept URI), but provides no guidance on alternatives like 'resolve_label' or when not to use this tool.

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

list_vocabulariesC

List all available vocabularies in the Skosmos instance

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Language code for labels (e.g. "en", "fi")

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It only states 'List all available vocabularies', omitting behavioral traits such as read-only nature, authentication requirements, or output format. The description adds minimal transparency beyond the basic 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?

A single sentence of 7 words that is front-loaded with the purpose. Every word is necessary and there is no fluff.

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 is simple, but with no output schema and no annotations, the description should explain what the output contains (e.g., vocabulary IDs, labels) or whether there is pagination. The current description is too sparse to be fully self-contained.

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 describes the 'lang' parameter. The description does not add any additional meaning or usage context for the parameter, so it meets the baseline but provides no extra value.

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 the verb 'List' and resource 'all available vocabularies' in the Skosmos instance. It is specific enough to distinguish from sibling tools which are mostly about individual concepts or searches, though it does not explicitly differentiate from 'get_vocabulary'.

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 on when to use this tool versus alternatives like 'get_vocabulary' or 'search_concepts'. It does not mention prerequisites, use cases, or exclusions.

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

narrower_conceptsB

BFS traversal of narrower (child) concepts down to a specified depth

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	Starting concept URI
`lang`	No	Language code
`depth`	No	Maximum traversal depth
`vocabulary`	Yes	Vocabulary identifier

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses the traversal algorithm (BFS), scope (narrower concepts), and depth parameter. However, it omits behavior when depth is omitted (depth is optional in schema), return format, pagination, or performance considerations. Adequate but not thorough.

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?

Description is a single, front-loaded sentence with no extraneous words. It efficiently conveys the core action and key constraints.

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?

Given 4 parameters, no output schema, and no annotations, the description is incomplete. It lacks details on optional behavior (depth), return structure, edge cases, or usage prerequisites. The agent may struggle to use this tool effectively without additional documentation.

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%, so baseline 3. The description adds the 'BFS traversal' context but does not explain parameter interplay or formatting beyond what the schema provides. No extra semantic enrichment, so score remains at baseline.

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?

Description clearly states 'BFS traversal of narrower (child) concepts down to a specified depth', specifying the algorithm (BFS), relationship direction (narrower/child), and depth limitation. It distinguishes from siblings like broader_concepts and related_concepts, making the purpose unambiguous.

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 explicit guidance on when to use this tool versus alternatives. While the description implies use for fetching child concept hierarchies, it does not mention when to avoid it (e.g., for direct children only, use get_concept instead) or contrast with traverse_concepts. The agent must infer context from sibling names.

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

related_conceptsB

BFS traversal of related concepts up to a specified depth

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	Starting concept URI
`lang`	No	Language code
`depth`	No	Maximum traversal depth
`vocabulary`	Yes	Vocabulary identifier

TDQS

B3.1/5.0

Behavior3/5

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

The description mentions BFS algorithm and depth limitation, adding behavioral context beyond a generic 'get related concepts'. However, with no annotations provided, it fails to disclose whether the operation is read-only, how cycles are handled, or what the output format is.

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 a single concise sentence with no unnecessary words. It efficiently conveys the core operation, though it could benefit from additional structure to separate input/output details.

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?

Given the complexity of a graph traversal tool, the description is insufficient. It does not explain the return value, result order, limits on results, or error conditions. The absence of an output schema increases the need for description completeness, which is not met.

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 all 4 parameters with clear definitions (100% coverage). The description adds the algorithmic detail of BFS but does not augment parameter meaning beyond what the schema provides, so baseline 3 is appropriate.

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 the tool performs a BFS traversal of related concepts with depth control. However, it does not distinguish this from sibling tools like 'traverse_concepts', 'broader_concepts', or 'narrower_concepts', which may overlap in functionality.

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 on when to use this tool versus alternatives. Siblings such as 'broader_concepts' and 'narrower_concepts' suggest more specific traversals, but the description does not clarify when 'related_concepts' is appropriate or when to use other traversal tools.

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

resolve_labelC

Resolve a label text to concepts in a vocabulary

ParametersJSON Schema

Name	Required	Description
`lang`	No	Language code
`text`	Yes	Label text to resolve
`vocabulary`	Yes	Vocabulary identifier

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description should carry behavioral details, but it only states the function. Missing information on case sensitivity, exact vs fuzzy matching, multiple matches, or response format.

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 clear sentence with no wasted words. Every part is necessary for stating the core function.

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?

Given the tool's simplicity and lack of output schema, the description is too sparse. It omits important context like what 'resolve' entails (exact match? returns multiple concepts?), which would help the agent anticipate behavior.

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 description adds minimal value beyond repeating parameter names. The baseline of 3 is appropriate because the schema already documents each parameter's meaning.

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 the verb 'resolve' and the resource 'a label text to concepts in a vocabulary', making the tool's purpose specific. However, it does not explicitly differentiate it from siblings like 'search_concepts' or 'autocomplete', though the action is distinct enough.

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 on when to use this tool versus its many siblings (e.g., search_concepts, autocomplete, get_concept). There are no when-not or alternative recommendations.

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

search_conceptsA

Full-text search for concepts across one or all vocabularies

ParametersJSON Schema

Name	Required	Description
`lang`	No	Language code
`query`	Yes	Search query string
`offset`	No	Result offset for pagination
`maxhits`	No	Maximum number of results
`vocabulary`	No	Limit search to this vocabulary

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided. Description only says 'full-text search' and does not disclose behavioral traits such as pagination behavior, result format, sorting, or field search scope. Schema parameters hint at pagination but description adds no 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?

Single sentence, no fluff, front-loaded with the essential purpose. Every word earns its place.

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?

With 5 parameters including pagination and no output schema, the description should explain return format or behavior. It only states purpose. Agent lacks info on response structure or how pagination works.

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%, baseline is 3. Description does not add any parameter-level information beyond what the schema provides. It does not clarify usage of 'vocabulary' or 'offset'/'maxhits' semantics.

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?

Description clearly states verb 'search', resource 'concepts', and scope 'across one or all vocabularies'. Distinguishes from siblings like autocomplete (prefix search) and get_concept (single concept retrieval).

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?

Implied usage: use for full-text search across concepts. No explicit when-not-to-use or mention of alternatives like autocomplete or concept_path. Guidance is minimal but not misleading.

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

traverse_conceptsB

BFS traversal using a mix of broader, narrower, and/or related relationships

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	Starting concept URI
`lang`	No	Language code
`depth`	No	Maximum traversal depth
`vocabulary`	Yes	Vocabulary identifier
`relationships`	Yes	Relationship types to traverse

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided; description only specifies BFS traversal but omits details about side effects, read-only nature, pagination, or output format. This leaves significant behavioral gaps.

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?

Single sentence that is front-loaded with key action (BFS traversal) and specifies relationship types. No extraneous text.

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?

Despite good schema coverage, the description lacks details on return values, traversal order, or limits. For a traversal tool with no output schema, more context is needed to 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?

Schema coverage is 100%, so parameters are well-documented structurally. Description adds context that the tool uses a mix of relationships, but does not explain parameter constraints or advanced usage beyond schema.

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?

Description clearly states it performs BFS traversal over concept relationships (broader, narrower, related). This distinguishes it from siblings like broader_concepts which only handle one relationship type.

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 on when to use this tool versus alternatives such as broader_concepts or narrower_concepts. The description does not mention scenarios where a mixed traversal is preferable.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

13 tool updatesv0.1.0Jul 9, 2026
- First observedautocomplete
- First observedbroader_concepts
- First observedconcept_path
- First observedget_concept
- First observedget_concept_label
- First observedget_vocabulary
- First observedlabels
- First observedlist_vocabularies
- First observednarrower_concepts
- First observedrelated_concepts
- First observedresolve_label
- First observedsearch_concepts
- First observedtraverse_concepts

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation3/5

Most tools have distinct purposes, but 'get_concept_label' and 'labels' overlap significantly, both retrieving labels for a concept URI. Additionally, 'broader_concepts' and 'traverse_concepts' can be confused since traverse supports broader traversal. This creates some ambiguity for an agent.

Naming Consistency4/5

Tool names mostly follow a consistent verb_noun pattern (e.g., list_vocabularies, get_concept, resolve_label). However, 'autocomplete' is a single word and 'concept_path' is noun_noun, breaking the pattern. The overall structure is clear despite these minor deviations.

Tool Count5/5

With 13 tools, the server is well-scoped for SKOS vocabulary browsing. It covers listing, searching, detail retrieval, and hierarchy traversal without being overwhelming. The count is appropriate for its purpose.

Completeness4/5

The tool surface covers core SKOS operations: vocabulary listing, concept details, labels, hierarchy traversal (broader, narrower, related), and search (autocomplete, full-text, label resolution). Missing are concept creation/modification (likely out of scope) and some non-core features like concept collections, but the browsing workflow is complete.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

openalex A
io.github.pipeworx-io
OpenAlex MCP — wraps the OpenAlex API (scholarly works, free, no auth)
Search Research & Data Open Data
362
Agent Skills Search Server
ai.com.mcp
Search and discover Agent Skills from the skills.sh registry. Powered by HAPI MCP server.
Search Agent Orchestration Developer Tools
28,776
OmegaAIOAuth
com.queryomega
Query, browse, and automate OmegaAI workspaces from any MCP client. Streamable HTTP with OAuth 2.0.
Workplace & Productivity App Automation
2
Nasa A
io.github.pipeworx-io
NASA MCP — wraps NASA Open APIs (api.nasa.gov)
Government Data Open Data Aerospace & Astrodynamics
362

Related MCP Servers

RDF4J MCP Server
Knowledge & Memory Databases Search
odysa
A
license
A
quality
D
maintenance
An MCP server that enables AI-powered exploration of RDF data and SPARQL querying via RDF4J. It provides tools for executing queries, searching knowledge graph resources, and retrieving schema summaries.
Updated 7 months ago (2026-02-07 17:57 UTC)
13
1
MIT
skill4agent MCP Server
Autonomous Agents Developer Tools Search
osulivan
A
license
B
quality
D
maintenance
MCP (Model Context Protocol) Server for skill4agent - Search, view, and install AI skills in AI conversations.
Updated 7 months ago (2026-02-20 08:19 UTC)
3
20
4
MIT
wot-mcp
Home Automation & IoT
macc-n
A
license
Not graded
quality
D
maintenance
Bridges Web of Things (WoT) devices to AI assistants via MCP, enabling discovery, monitoring, and control of IoT devices through natural language.
Updated 7 months ago (2026-02-04 19:39 UTC)
9
GPL 3.0
mcp-sparql
Search Knowledge & Memory Databases
daedalus
A
license
A
quality
C
maintenance
MCP server exposing SPARQL query functionalities for LLMs, enabling query execution, validation, and graph exploration across SPARQL endpoints.
Updated 3 months ago (2026-06-17 19:06 UTC)
7
MIT

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/jsilvanus/skosmos-mcp'

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

skosmos-mcp

Features

Installation

Docker / Docker Compose

Container Images from GitHub Container Registry

Configuration

MCP Tools Reference

Vocabulary Tools

list_vocabularies

get_vocabulary

Concept Tools

get_concept

get_concept_label

concept_path

Search Tools

search_concepts

autocomplete

resolve_label

Labels Tool

labels

Traversal Tools

broader_concepts

narrower_concepts

related_concepts

traverse_concepts

Assistance Tools

vocabulary_schema_overview

query_guidance

reconcile_concept

suggest_sparql_templates

SPARQL Tools

execute_sparql_query

execute_sparql_update

list_sparql_graphs

sparql_query_templates

MCP Resources

Traversal Examples

Get all ancestors of a concept (depth 3)

Mixed traversal (broader + related)

Using Optional Server URL Parameter

Example: Query a different Skosmos instance

Why use this feature?

stdio (standard MCP deployment)

StreamableHTTP

Claude Desktop (claude_desktop_config.json)

Development

Architecture

Key Design Decisions

License

Attribution

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`list_vocabularies`

`get_vocabulary`

`get_concept`

`get_concept_label`

`concept_path`

`search_concepts`

`autocomplete`

`resolve_label`

`labels`

`broader_concepts`

`narrower_concepts`

`related_concepts`

`traverse_concepts`

`vocabulary_schema_overview`

`query_guidance`

`reconcile_concept`

`suggest_sparql_templates`

`execute_sparql_query`

`execute_sparql_update`

`list_sparql_graphs`

`sparql_query_templates`

Claude Desktop (`claude_desktop_config.json`)