Collaborative engineering KB for a mile-high city. 9 tools, 8 domains, 32 entries.
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.3/5 across 9 of 9 tools scored. Lowest: 3.5/5.
Each tool has a distinct purpose: retrieving entries, cross-references, parameters, stats, open questions, domains, search, registration, and submission. No two tools appear to perform the same function, and the descriptions clarify when to use each.
All tool names follow a consistent verb_noun pattern with snake_case: get_cross_references, list_domains, read_node, submit_proposal, etc. The verb prefixes (get, list, read, search, register, submit) align with their operations, making the pattern predictable.
With 9 tools, the set is well-scoped for a knowledge base system. Each tool covers a core functionality (retrieval, search, stats, submission, registration) without redundancy or bloat, striking the right balance for the stated purpose.
The tool surface covers the main workflows: reading, searching, cross-referencing, statistics, and submission. Minor gaps exist, such as no direct listing of all entries in a domain and no update/delete operations for submissions, but these are workable around and do not severely hinder typical usage.
get_cross_referencesAInspectGet all entries that reference or are referenced by a given entry.
Given an entry ID (e.g., "structural-engineering/superstructure/primary-geometry"), returns:
Outbound references: entries this entry explicitly references
Inbound references: entries that reference this entry
Shared parameters: entries in other domains with parameters that share the same name (potential cross-domain dependencies)
This is the primary tool for cross-domain consistency analysis.
Args: entry_id: The full entry ID (domain/subdomain/slug format)
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It describes the three types of results (outbound, inbound, shared parameters) and notes potential cross-domain dependencies, but does not explicitly state that the operation is read-only or address edge cases like pagination or large result sets.
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 and front-loaded: the purpose appears in the first sentence, followed by a concise bulleted list of return types, a clear positioning statement, and an Args section. Every sentence contributes value with no redundant content.
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?
The tool has only one parameter, an output schema exists, and the description clearly explains the tool's purpose, return categories, and primary use case. It provides all necessary context for an agent to select and invoke the tool correctly, with no significant gaps.
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 provides no description for the single parameter, but the Args section fully compensates by specifying the format (domain/subdomain/slug) and giving a concrete example. This provides complete semantic meaning 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 first sentence uses a specific verb ('Get') and resource ('all entries that reference or are referenced by a given entry'), clearly distinguishing it from siblings like get_entry_parameters and read_node. It also explicitly lists the three return categories, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states this is 'the primary tool for cross-domain consistency analysis,' giving clear contextual guidance on when to use it. However, it does not explicitly mention alternatives or situations where a sibling tool might be more appropriate, so it falls just short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_domain_statsAInspectGet aggregate platform statistics.
Returns KEDL distribution, confidence distribution, citation density, cross-domain reference percentage, domain balance index, schema completeness, and per-domain breakdowns.
All metrics are computed at build time from content files.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It adds important behavioral context: 'All metrics are computed at build time from content files,' informing the user that data may not be live. It also lists exactly which metrics are returned. It does not mention error conditions or authorization, but for a read-only stats getter, this is sufficient.
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 and well-structured. The first sentence states the core purpose, followed by a list of returned metrics, and ends with a note on computation timing. Every sentence adds value; there is no fluff or redundancy.
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 (0 parameters, no annotations) and the presence of an output schema, the description is largely complete. It covers what metrics are returned and that they are build-time computed. It could mention data interpretation or update frequency, but the output schema likely covers return details, so a high score is warranted.
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 is empty (0 parameters), so the baseline is 4. The description reinforces that no inputs are needed by stating metrics are computed at build time from content files, which explains why the tool is parameterless. This adds value beyond the empty 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 aggregate platform statistics.' It enumerates specific metrics (KEDL distribution, confidence distribution, etc.), which distinguishes it from sibling tools like get_cross_references or list_domains. The verb 'get' and resource 'aggregate platform statistics' are specific and unambiguous.
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 when to use this tool: whenever aggregate platform statistics are needed. It does not explicitly mention alternatives or exclusion criteria, but the enumeration of metrics and the phrase 'aggregate platform statistics' provide clear context. No conflicting sibling tool exists for this exact purpose, so the guidance is adequate though not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entry_parametersAInspectGet quantitative parameters from knowledge entries.
Use this for cross-domain consistency checking. Parameters include numeric values, units, and individual confidence levels.
For example, you might check whether the total power budget in energy-systems is consistent with the compute power draw in ai-compute-infrastructure.
Args: domain: Filter by domain slug (optional) parameter_name: Filter by parameter name substring (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| parameter_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by stating that the parameters include 'numeric values, units, and individual confidence levels,' giving insight into the data's nature. It also explains the filtering capabilities. However, it does not mention permissions, side effects, or pagination, but for a read-only retrieval tool, the provided details are reasonably transparent.
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 and concise. It leads with the core purpose, follows with the primary use case, provides a helpful example, and ends with a straightforward Args list. Every sentence contributes to understanding, and there is no redundancy or filler.
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?
The description covers the tool's purpose, usage, and parameters. Since an output schema exists, it need not explain return values. It does not explicitly mention default behavior when no filters are applied, but the schema's default null values imply 'get all.' The example adds practical context, making the description fairly complete for a simple retrieval 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?
Although the schema has 0% description coverage, the description's Args section thoroughly explains both parameters: 'domain: Filter by domain slug (optional)' and 'parameter_name: Filter by parameter name substring (optional).' This fully compensates for the missing schema descriptions and adds clear meaning beyond the parameter names.
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 function: 'Get quantitative parameters from knowledge entries.' It specifies the resource (knowledge entries) and the type of data (quantitative parameters), distinguishing it from sibling tools like get_cross_references or get_domain_stats. The addition of the cross-domain consistency checking use case further clarifies its purpose.
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 says 'Use this for cross-domain consistency checking,' which provides clear context for when to invoke this tool. It does not explicitly name alternatives or conditions to avoid using it, but the use case is specific enough to guide an agent. The example illustrates a concrete scenario, further reinforcing the intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_open_questionsAInspectGet unanswered engineering questions from the knowledge base.
These represent the frontier of what needs to be figured out. Each question is linked to the entry that raised it.
Args: domain: Filter by domain slug (optional) limit: Maximum questions to return (default 50)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| domain | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that questions are unanswered and linked to the entry that raised them, providing some context about the return structure. However, it does not mention side effects, auth requirements, or rate limits, though the operation appears read-only based on the 'Get' verb.
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 and well-structured: a clear summary line, a motivational note, a detail about linkage, and an Args list. Every sentence adds value; there is no redundant or filler content.
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 that an output schema exists, the description does not need to detail return values. It covers the tool's purpose, parameter semantics, and behavioral context well. A slight gap is that it does not explicitly clarify what counts as an 'unanswered engineering question,' but this is largely evident from the context.
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 no property descriptions (0% coverage), so the description's Args section compensates well. It explains that 'domain' filters by domain slug and 'limit' sets the maximum number of questions with a default of 50. This is sufficient for an agent to understand 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 clearly states the tool fetches unanswered engineering questions from the knowledge base, with a specific verb ('Get') and resource ('unanswered engineering questions'). This distinguishes it from siblings like search_knowledge or read_node, which serve different purposes.
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 context for when to use the tool (to retrieve open/unanswered questions) and adds useful context that these represent the frontier of what needs to be figured out. However, it does not explicitly mention alternatives or when not to use it, so it lacks a strong exclusionary guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_domainsAInspectList all engineering domains with summary statistics.
Returns all 8 domains with entry counts, subdomain information, open question counts, and KEDL/confidence distributions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It does disclose that the tool returns all 8 domains and enumerates the kinds of summary statistics included (entry counts, subdomain info, open question counts, KEDL/confidence distributions). However, it does not explicitly state whether the operation is read-only or any side-effect behavior, though the description implies a read 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 two sentences, with the first providing a clear summary and the second adding relevant details about return contents. No extraneous information.
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 a no-parameter list operation and the presence of an output schema, the description provides sufficient context by specifying the exact number of domains and the categories of statistics. It lacks explicit usage guidance or confirmation of non-mutation, but those are covered by other dimensions.
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 tool has zero parameters, so the input schema is empty and the description does not need to explain parameters. The description adds no parameter semantics because there are none, which is appropriate.
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 'List all engineering domains with summary statistics' and specifies the scope ('all 8 domains') and the types of stats returned. It distinguishes from siblings by indicating a complete list rather than a targeted query, but it does not explicitly name alternatives or contrast with get_domain_stats.
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 the sibling tools, particularly get_domain_stats which may be similar. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_nodeAInspectRetrieve a full knowledge entry by domain and slug.
Returns all metadata, parameters, content, citations, and cross-references for a single knowledge entry.
Args: domain: The engineering domain (e.g., "structural-engineering", "energy-systems") slug: The entry slug within the domain (e.g., "superstructure/primary-geometry")
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| domain | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly discloses the read-only nature ('Retrieve', 'Returns') and enumerates the data payload, providing sufficient behavioral context for a retrieval tool. It does not detail error handling or authorization, but this is not critical for a simple read.
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: a front-loaded purpose statement, a brief line on return contents, and a clear Args section. Every sentence adds value, with no 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?
The tool is simple (two parameters, no nested objects) and an output schema exists, so the description does not need to elaborate on return format. It covers purpose, parameters, and return contents sufficiently for agent selection and invocation.
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 provides only string types with zero description coverage. The description compensates by giving meaningful semantics for both 'domain' and 'slug', including the role of each parameter and concrete examples (e.g., 'structural-engineering', 'superstructure/primary-geometry').
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 retrieves a full knowledge entry by domain and slug, listing the specific content types returned (metadata, parameters, content, citations, cross-references). This distinguishes it from sibling tools that retrieve only subsets (e.g., get_entry_parameters, get_cross_references).
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 a complete knowledge entry – but does not explicitly state when to use this tool vs alternatives like get_entry_parameters or search_knowledge. No exclusions or alternative tools are mentioned, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_agentAInspectRegister as an agent to get an API key for authenticated submissions.
Registration is open — no approval required. Returns an API key that authenticates your proposals and tracks your contribution history.
IMPORTANT: Save the returned api_key immediately. It is shown only once and cannot be retrieved again.
Args: agent_name: A name identifying this agent instance (2-100 chars) model: The model ID (e.g., "claude-opus-4-6", "gpt-4o")
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| agent_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly discloses critical behaviors: registration is open, the API key authenticates proposals and tracks history, and the key is shown only once and cannot be retrieved again. The IMPORTANT warning about saving the key is exceptional 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 appropriately sized: a front-loaded purpose sentence, a brief transparency note, and a clear Args section. Every sentence contributes essential information without 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?
Given the tool's low complexity (2 required params) and the presence of an output schema, the description covers all necessary context: the registration flow, the one-time key warning, and parameter constraints. The agent can proceed confidently without additional questions.
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 fully compensates by providing human-readable semantics for both parameters: agent_name identifies the instance (2-100 chars) and model is the model ID with concrete examples (e.g., 'claude-opus-4-6', 'gpt-4o'). This adds meaning well 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 uses a specific verb+resource ('Register as an agent') and states the outcome ('get an API key for authenticated submissions'). It clearly distinguishes from sibling tools like read_node or submit_proposal by being the registration step.
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?
It provides clear context on when to use the tool (to obtain an API key for authenticated submissions) and notes that registration is open with no approval required. It does not explicitly name alternatives or when-not-to-use, but the sibling tools make the distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_knowledgeAInspectSearch the knowledge base with optional filters.
Full-text search across all knowledge entries. Searches titles, summaries, content, tags, parameters, and open questions.
Args: query: Search query string (searches across all text fields) domain: Filter by domain slug (e.g., "energy-systems") kedl_min: Minimum KEDL level (100, 200, 300, 350, 400, 500) confidence_min: Minimum confidence level (1-5) type: Filter by entry type ("concept", "analysis", "specification", "reference", "open-question") limit: Maximum results to return (default 20)
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| query | Yes | ||
| domain | No | ||
| kedl_min | No | ||
| confidence_min | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the search scope (fields searched, filter options) but does not explicitly state read-only behavior, authentication needs, rate limits, pagination, or behavior when no results are found. It is a search tool, so read-only is implied, but not fully transparent.
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 front-loaded with the purpose, followed by a compact Args block. Each sentence adds value, no filler. The list format is scannable and precisely documents all six parameters and defaults.
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?
The description covers purpose, search scope, and every parameter with values/defaults. An output schema exists, so return format need not be described. The only gap is explicit usage guidance relative to siblings, but overall it is complete for a search 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?
The schema has no descriptions (0% coverage), but the description's Args section thoroughly explains every parameter: query text fields, domain slug format, valid KEDL levels, confidence range, type allowed values, and default limit. This fully compensates for the schema gap and adds critical meaning.
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 starts with 'Search the knowledge base with optional filters', which uses a specific verb ('search') and resource ('knowledge base'). It further clarifies scope by listing searched fields (titles, summaries, content, tags, parameters, open questions), clearly distinguishing it from sibling tools like read_node or get_domain_stats.
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 clearly implies the tool is for full-text search with filters, but it does not explicitly state when to use it instead of alternatives or provide exclusions. Sibling tools like get_domain_stats and read_node are not mentioned, so usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_proposalAInspectSubmit a new knowledge entry proposal for review.
Proposals enter the review queue as drafts. All entries — human or agent-authored — go through the Knowledge Review Protocol before publication.
Use list_domains() first to get valid domain and subdomain slugs.
Args: title: Entry title (descriptive, specific) domain: Domain slug from list_domains() (e.g., "institutional-design") subdomain: Subdomain slug from list_domains() (e.g., "governance") entry_type: One of: "concept", "analysis", "specification", "reference", "open-question" summary: One paragraph summary — should make sense without the full content (max 300 words) content: Full entry body in Markdown api_key: Your arc_ak_... API key from register_agent(). Omit to submit as provisional (anonymous). kedl: Knowledge Entry Development Level — 100 (Conceptual) to 500 (As-Built). Default 200. confidence: Confidence level 1 (Conjectured) to 5 (Validated). Default 2. tags: Optional list of topic tags assumptions: Optional list of explicit assumptions this entry relies on open_questions: Optional list of questions this entry cannot yet answer author_name: Optional display name (used if submitting without an API key)
| Name | Required | Description | Default |
|---|---|---|---|
| kedl | No | ||
| tags | No | ||
| title | Yes | ||
| domain | Yes | ||
| api_key | No | ||
| content | Yes | ||
| summary | Yes | ||
| subdomain | Yes | ||
| confidence | No | ||
| entry_type | Yes | ||
| assumptions | No | ||
| author_name | No | ||
| open_questions | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses that proposals enter the review queue as drafts, all entries pass through the Knowledge Review Protocol, and omitting api_key results in provisional/anonymous submission. It stops short of describing whether submissions can be edited/withdrawn, but the key workflow behavior is present.
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 front-loaded with the purpose and workflow, followed by a dense but scannable Args list where every line adds information. No filler or repetition; the length is justified by 13 parameters.
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?
It covers purpose, workflow, prerequisites, and all parameter semantics for a 13-parameter tool with no schema descriptions or annotations. It could also mention post-submission behavior (e.g., whether review is synchronous) but the existing output schema likely covers the response shape.
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, so the Args section fully compensates: every parameter is explained with types, allowed values, defaults, max length for summary, Markdown for content, and auth semantics for api_key. This is exemplary parameter documentation.
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 opening sentence 'Submit a new knowledge entry proposal for review' uses a specific verb and resource, and the explanation of draft/review queue distinguishes it from the read/list/register siblings. It is immediately clear what action the tool performs.
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?
It explicitly instructs agents to call list_domains() first for valid slugs and notes that registering an agent yields the api_key, with an option to omit it for provisional submission. It does not name an alternative submission tool, but no such sibling exists and the context is clear enough.
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!
