Server Details
Learn and adopt the Capability Host Protocol — the agentic web's open evidence layer.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.4/5 across 9 of 9 tools scored. Lowest: 2.7/5.
Each tool targets a distinct aspect of the CHP ecosystem: defining primitives, explaining concepts, FAQs, retrieving capabilities, examples, adoption steps, listing adapters, listing capabilities, and searching. No overlapping purposes are evident.
Most tool names follow a verb or verb+noun pattern (define, explain, get_capability, list_adapters, search), with consistent use of lowercase and underscores. 'faq' and 'how_to_adopt' deviate slightly but are still clear and readable.
With 9 tools covering definitions, explanations, FAQs, capabilities, examples, adoption, adapters, and search, the set is well-scoped for an onboarding and reference server—neither too sparse nor too heavy.
The tool surface comprehensively covers learning about CHP: from defining terms and explaining concepts to listing capabilities, retrieving examples, and getting adoption steps. No obvious gaps for the intended purpose.
Available Tools
9 toolsdefineDefine a CHP termAInspect
Define a CHP primitive. Pass a term, or omit to list the glossary.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes two distinct behaviors (define vs. list), but lacks details on side effects, authentication, or return format. For a read-only definition tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers core functionality. It lacks return format details but the behavior (definition or list) is self-explanatory. Complete enough for a basic glossary tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indicates the parameter 'term' is optional and its omission triggers listing. However, it does not specify format, examples, or error handling for invalid terms. This adds some semantic value but not full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Define a CHP primitive.' It distinguishes between two modes: pass a term for a definition, or omit to list the glossary. This differentiates it from sibling tools like 'explain' or 'faq'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Pass a term, or omit to list the glossary.' This tells the agent when to use each mode but does not compare with alternatives or specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explainExplain a CHP conceptAInspect
Learn what CHP is and how it works. Pass a topic, or omit to list topics. Topics: what-is-chp, evidence-model, why-a-protocol, governance, agentic-web, evidence-vs-telemetry, chp-vs-mcp, conformance.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It discloses that the tool provides explanations and lists topics, but does not mention whether it is read-only, any authentication needs, or error handling for invalid topics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two sentences, front-loading the purpose. The list of topics is clear but could be more structured (e.g., bullet points). Nearly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should indicate return format. It does not specify whether the response is plain text, HTML, or structured data. Also lacks error handling or outcome for invalid topics. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one optional parameter 'topic' with 0% schema description coverage. The tool description compensates by listing valid topics ('what-is-chp', 'evidence-model', etc.), adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool explains CHP concepts with verb 'Learn' and resource 'CHP concept'. It lists specific topics, distinguishing it from siblings like 'define' or 'faq' which likely offer formal definitions or FAQs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states usage pattern: pass a topic to get an explanation, or omit to list available topics. However, it does not provide guidance on when not to use this tool vs alternatives like 'define' or 'how_to_adopt'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faqCHP FAQBInspect
Common questions about CHP. Pass a query to filter, or omit for all.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Tool Definition Quality
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 filtering behavior but does not mention any other behavioral traits such as rate limits, pagination, or what constitutes 'common questions'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single sentence that is front-loaded with the purpose. It could be slightly expanded to include more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is insufficiently complete. It does not describe the output format or contents, nor does it clarify how this tool differs from similar ones like 'explain'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'query' with zero description coverage. The description adds that this parameter is for filtering, which provides some meaning beyond the schema. However, it does not specify the expected format or matching behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides common questions about CHP and allows filtering via a query parameter. It distinguishes from siblings like 'search' (more generic) and 'define' (specific definitions). However, 'CHP' is not explicitly defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic guidance: pass a query to filter or omit for all. It does not specify when not to use this tool or mention alternatives like 'search' for more specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_capabilityGet a capability descriptorCInspect
Resolve a capability id to its descriptor.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. The description only says 'resolve a capability id to its descriptor' without describing whether the operation is read-only, what happens on invalid id, or if it returns a single object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it lacks essential details like parameter explanation and usage context. It is not optimally informative despite being short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and sibling tools exist. The description does not explain what a 'descriptor' is or what the response contains, making it insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no value beyond the schema. The parameter 'id' is just a string with no explanation of format, examples, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resolve a capability id to its descriptor' uses a specific verb 'resolve' and resource 'capability id' to clearly state the tool's function. It distinguishes from sibling tools like 'list_capabilities' which lists all, and 'search' which is broader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'list_capabilities' or 'search'. Lacks context such as prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_exampleGet a CHP code exampleAInspect
Get a runnable example. Pass a name, or omit to list examples. Names: hooks-install, inspect-session, minimal, agentic, rag, safety, persistence, evidence-output.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool returns a runnable example and lists valid names, but does not disclose behavior for invalid names, side effects, or authentication requirements. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no wasted words. It front-loads the action ('Get a runnable example') and provides essential details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is complete. It covers how to retrieve a specific example, how to list examples, and the valid names. No additional information is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by listing possible values for the 'name' parameter ('hooks-install, inspect-session, minimal, agentic, rag, safety, persistence, evidence-output') and explaining the default behavior (omit to list). This adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a runnable example.' It specifies that you can pass a name to get a specific example or omit to list examples, and it enumerates valid names, distinguishing it from sibling tools like 'explain' or 'faq'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Pass a name, or omit to list examples.' It indicates when to use the tool for a specific example versus listing available ones. However, it does not explicitly exclude cases or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
how_to_adoptHow to adopt CHPAInspect
Get the steps to start using CHP (begin with agents).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full burden. It only states it provides steps, but does not reveal any behavioral traits like whether it returns a list or a narrative, or if it requires prior knowledge.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded with key information. However, it could be slightly more descriptive without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or parameters, the description is adequate but minimal. It does not explain the return format or how it differs from similar tools like 'faq'. Lacks enough context for an agent to fully understand the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so no semantic addition needed. Baseline is 4. The description does not add any parameter info, but that is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides steps for starting to use CHP, specifying 'begin with agents'. This distinguishes it from sibling tools like 'define' or 'faq' which are informational rather than procedural.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for getting started steps, but does not explicitly state when to use it over alternatives such as 'get_example' or 'faq'. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_adaptersList adaptersCInspect
Browse the open adapter ecosystem, optionally by category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the burden falls entirely on the description. It only says 'Browse... optionally by category' without disclosing output format, pagination, authentication needs, or any side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is appropriately short for a simple tool, though it sacrifices some necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (1 optional parameter, no output schema), the description lacks completeness. It does not specify what the output contains, how it relates to siblings like 'search', or any limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'category' has 0% schema description coverage. The description hints at its purpose ('by category') but does not explain allowed values, behavior when omitted, or how it filters results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Browse') and resource ('open adapter ecosystem'), and distinguishes it from siblings like 'search' which implies more specific queries. It is specific and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'search' or 'list_capabilities'. The optional category filter is mentioned but without context on when it's appropriate to apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_capabilitiesList capabilitiesBInspect
List the capabilities the open CHP adapter ecosystem declares, optionally by category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action ('list') without disclosing behavioral traits such as read-only nature, performance considerations, or any side effects. This is minimal disclosure for a tool that likely interacts with a system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence that conveys the essential information without any unnecessary words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema, no annotations), the description is adequate but has gaps. It explains the purpose and parameter but lacks details on category values, return structure, or query behavior. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. The description mentions the parameter 'category' as an optional filter but does not define valid values, format, or provide examples. With only one parameter, this is insufficient to fully understand its usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'capabilities', and mentions optional filtering by category. It distinguishes from sibling tools like get_capability (which retrieves a single capability) by implying a bulk listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing capabilities but provides no explicit guidance on when to use this tool versus alternatives like get_capability, how_to_adopt, or other sibling tools. The optional category filter is mentioned but not explained in terms of when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch CHPBInspect
Search CHP concepts, glossary, FAQs, and the capability catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks disclosure of behavioral traits such as whether it's read-only, returns brief or detailed results, or any limits. For a search tool, more transparency expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of 10 words, front-loaded and efficient. Every word adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter, the description is adequate but omits return format or pagination details. Given no output schema, a bit more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds context by specifying what the query searches across (concepts, glossary, etc.). However, it doesn't describe the query format, case sensitivity, or any additional constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Search' and the specific resources: CHP concepts, glossary, FAQs, and capability catalog. It distinguishes itself from specific sibling tools like 'define' or 'faq' by covering a broad range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings. It implies use for broad search but doesn't indicate when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!