context-hub
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| context_getB | Search, read a stable ref, or inspect the public manifest. Responses include a context_hub invocation marker and source summary. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With only a single tool, there is no possibility of confusing it with another tool. The tool's description clearly covers its purpose without overlapping with anything else.
The lone tool 'context_get' follows a clear snake_case convention with a verb_noun pattern. While there is no set to compare against, the name is consistent with common MCP naming practices.
Having only one tool for a context hub is severely under-scoped. The description implies multiple capabilities (search, read, inspect manifest) that would typically be split into separate tools, making the single tool feel like a catch-all.
The tool covers read-only operations but lacks any management, listing, or mutation capabilities. For a context hub, one would expect at least tools to create or update contexts, or to list available contexts, which are missing here.