A connector providing AI assistants searchable access to climate-aligned contract clauses, glossary terms, and practical guides from The Chancery Lane Project's curated knowledge graph.
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.
Average 4.6/5 across 4 of 4 tools scored. Lowest: 4/5.
Each tool targets a distinct retrieval mode: exact entity matching (entity_lookup), relevance-ranked free-text search (search), faceted filtering (taxonomy_content), and facet vocabulary discovery (taxonomy_facets). The descriptions explicitly contrast entity_lookup and search, and the two taxonomy tools have a clear dependency, leaving no ambiguity about which tool to use.
All names use lowercase snake_case, but the structure varies: 'search' is a bare verb, 'entity_lookup' is noun+verb, and 'taxonomy_content'/'taxonomy_facets' are noun+noun with a shared prefix. This is readable and mostly predictable, though not perfectly uniform.
With only 4 tools, the server is well-scoped for a read-only knowledge graph query interface. Each tool has a distinct role and none feel redundant; the count is comfortably within the ideal range for a focused purpose.
The set covers the core query workflows: free-text search, exact entity lookup, faceted browsing, and facet discovery. A minor gap is the lack of a direct fetch by ID/URL, but search and entity_lookup with full-text inclusion can retrieve content, so most use cases are supported.
entity_lookupAInspectFind TCLP content nodes (clauses, glossary terms) associated with a named concept.
Unlike `search`, this performs a deterministic name match against Entity nodes in
the knowledge graph rather than a relevance-ranked semantic search. Use it when
you have a specific term or concept (e.g. "scope 3 emissions", "net zero") and
want to retrieve every clause or glossary entry that explicitly references it.
Args:
name: The entity or concept name to look up (exact match, case-insensitive).
limit: Maximum number of results to return (1–50).
include_full_text: Include each hit's full body text (Markdown). Off by
default — bodies are large; request only when you need the content,
and prefer a small `limit` when you do.
Returns:
JSON with "meta" and "results" where each hit includes the source content
node and the entity names that matched.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| limit | No | ||
| include_full_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses key behavioral traits: deterministic matching, case-insensitivity, default off for `include_full_text`, and the rationale (bodies are large) implying performance awareness. It also specifies the return structure. It stops short of noting potential failure modes or behavior on empty results, but given the simplicity of a lookup, this is solid coverage.
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 well-structured with a summary, a comparative note, a usage sentence, and clearly labeled Args/Returns sections. Every sentence serves a purpose—no filler or repetition. The format makes it easy to scan while retaining all essential details.
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 tool with no output schema and no annotations, the description covers all necessary context: purpose, distinction from siblings, parameter semantics, usage tips, and return shape. It is fully self-contained and leaves no major ambiguity about how to invoke the tool or interpret results.
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 description coverage, the description fully compensates by explaining each parameter's semantics: `name` is exact match and case-insensitive, `limit` is a range (1–50), and `include_full_text` is off by default with guidance to request it only when needed and prefer small limits. This is precisely the value a description should add beyond the raw 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 opens with a specific verb ('Find') and resource ('TCLP content nodes'), and clearly scopes the action ('associated with a named concept'). It immediately distinguishes itself from the sibling `search` tool by contrasting deterministic name matching with relevance-ranked semantic search, which makes its unique purpose unmistakable.
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 explicitly contrasts with `search` and states exactly when to use this tool: 'Use it when you have a specific term or concept... and want to retrieve every clause or glossary entry that explicitly references it.' This is clear, actionable guidance that also implicitly conveys when `search` would be preferred (fuzzy or ranked results).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspectSearch the TCLP knowledge graph using fusion search (semantic + BM25).
Args:
query: Free-text search query (max 1000 characters).
node_type: Content scope — "tclp" (clauses, glossary terms, guides),
"lrsf" (laws, regulations, standards, frameworks), or "all".
limit: Maximum number of results to return (1–50).
rerank: Whether to apply RRF reranking when combining graph and text results.
include_full_text: Include each hit's full body text (Markdown). Off by
default — bodies are large; request only when you need the content,
and prefer a small `limit` when you do.
Returns:
JSON with "meta" (totals, timing) and "results" (ranked hits with title,
url, content_type, scores, and optionally relationships and full_text).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| rerank | No | ||
| node_type | No | all | |
| include_full_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behaviors: fusion search mechanism, RRF reranking option, default off for full text with a size warning, and the return structure. It does not mention rate limits or auth, but these are less critical for a read-only search tool. The extra context about result contents (meta, results with titles, scores) goes beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear Args and Returns sections, and every sentence provides useful information. It is somewhat long but not wasteful; the detail on include_full_text and limit is practical. The opening sentence is a concise summary, making it front-loaded.
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?
Without an output schema, the description explicitly details the return JSON structure and result fields. It covers parameters, defaults, and edge cases like large bodies. Missing information like pagination or error handling is minor for a search tool, so the description is sufficiently complete for an agent to use it correctly.
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 schema has 0% description coverage, but the description thoroughly explains every parameter: query max length, node_type allowed values, limit range, rerank meaning, and include_full_text caveat. This fully compensates for the schema's lack of descriptions, providing all necessary semantics for correct invocation.
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 'Search the TCLP knowledge graph using fusion search (semantic + BM25),' specifying the verb (search), resource (TCLP knowledge graph), and method (fusion search). This distinguishes it from sibling tools like entity_lookup, taxonomy_content, and taxonomy_facets, which are more specialized lookups.
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 no guidance on when to use this tool versus the sibling alternatives. It includes parameter-level advice (e.g., 'request only when you need the content, and prefer a small limit'), but no exclusions or criteria for tool selection relative to other available tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
taxonomy_contentAInspectList TCLP content (clauses, guides) filtered by taxonomy facet=value.
Multi-facet filters are combined with AND. Call `taxonomy_facets` first
to learn which facet names and slugs exist; using a name not in that
list returns a 400.
Args:
filters: Mapping of facet name to value slug, e.g.
`{"sector": "real-estate", "practice_area": "commercial"}`.
Each facet may appear at most once.
scope: `clause`, `guide`, or `all` (default).
limit: Maximum results to return (1–100, default 25).
offset: Result offset for paging (default 0).
sort: `title`, `date_published_desc`, or `date_modified_desc`.
Returns:
JSON with "meta" (totals, scope, filters echoed back) and "results"
(each hit has `id`, `url`, `title`, `content_type`, dates, and a
`facets` map of all taxonomy arrays on the node).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | title | |
| limit | No | ||
| scope | No | all | |
| offset | No | ||
| filters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral details: multi-facet AND logic, the 400 error on invalid facet names, that each facet may appear at most once, the limit range (1–100), defaults, sort options, and the exact return structure. This is strong, though it doesn't mention authentication or rate limits, which might be relevant for a read-only listing tool.
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 well-structured, starting with a one-line summary, followed by bullet-like Args and Returns sections. Every sentence adds value—no fluff. Despite the length, it is appropriately sized for the tool's complexity.
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 annotations and no output schema, the description covers all necessary aspects: what it does, prerequisites, error conditions, every parameter with defaults and constraints, and the return format. An agent can confidently invoke the tool correctly based on this text alone.
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 coverage is 0% (parameters have no descriptions in the schema), so the description fully compensates. It explains each parameter: filters mapping with an example, scope options, limit range and default, offset default, and sort enum values. The nested object structure of filters is clarified with a concrete example.
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 uses a specific verb ('List') and identifies the exact resource ('TCLP content') plus the filtering mechanism ('taxonomy facet=value'). It clearly distinguishes itself from sibling tools like taxonomy_facets (which lists facets) and search/entity_lookup by stating its scope.
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 explicitly instructs to call taxonomy_facets first to learn valid facet names, and notes that invalid names return a 400. It also explains that multi-facet filters are AND-combined. However, it does not explicitly contrast with search or entity_lookup, leaving some uncertainty about when those alternatives should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
taxonomy_facetsAInspectList taxonomy facets and their value slugs across TCLP content.
Facets are taxonomy categories like `sector`, `practice_area`,
`application`, and `jurisdiction`. Each facet returns the list of slugs
that actually appear on the graph, with counts. Use this to discover
the vocabulary, then call `taxonomy_content` with chosen slugs.
Args:
scope: Which labels to include — `clause` (ClauseName only),
`guide` (Guide only), or `all` (both, the default).
Returns:
JSON with "meta" and "facets". Each facet has `name`, `applies_to`
(list of Neo4j labels carrying it), and `values` (list of
`{slug, count}`, sorted by count desc).
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the return structure (meta, facets, values with counts), sorting order, and scope default behavior. It explains what the tool produces in sufficient detail for a read-only listing, though it does not mention potential edge cases or performance characteristics.
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 well-structured with a clear first sentence, followed by a compact explanation, parameter details, and a return specification. Every sentence provides necessary information without redundancy or 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 single-parameter tool with no output schema, the description supplies all essential context: it lists sibling relationships, explains the returned data shape, and clarifies the scope behavior. It is entirely sufficient for an agent to select and invoke the tool correctly.
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 schema only defines 'scope' with a default, but the description thoroughly explains the accepted values ('clause', 'guide', 'all') and what each means. Since schema description coverage is 0%, this description fully compensates by adding crucial parameter semantics.
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 immediately states 'List taxonomy facets and their value slugs across TCLP content', using a specific verb and resource. It clearly distinguishes the tool's focus on discovering vocabulary from sibling tools like taxonomy_content, which is for content retrieval.
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 instructs when to use the tool: 'Use this to discover the vocabulary, then call taxonomy_content with chosen slugs.' This provides clear context and directs to the appropriate sibling tool, leaving no ambiguity about workflow.
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.
No comments yet. Be the first to start the discussion!
