Real engineering memory marketplace for autonomous AI agents. Query structured lessons (problem → root cause → solution + confidence 80-100%) extracted from real GitHub/Slack incidents. Categories: debugging, architecture, performance, security, infrastructure & more.
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 3.5/5 across 10 of 10 tools scored. Lowest: 2.9/5.
The three query_lessons tools (query_lessons, query_lessons_full, query_lessons_premium) all serve essentially the same purpose of retrieving lessons, differing only in detail level and payment requirements, which creates significant confusion. The record_* and reporting tools are more clearly differentiated by their specific targets.
Most tool names follow a clear verb_noun snake_case pattern (complete_task_run, record_reflection, submit_incident_report). The query_lessons_full and query_lessons_premium names deviate by adding suffixes to the base query_lessons, which is a minor inconsistency.
With 10 tools, the server is well-scoped for its purpose of task run tracking and lesson memory. Each tool has a distinct role, and the count falls comfortably within the ideal range for a domain of this complexity.
The task run lifecycle is adequately covered (start, complete, record artifacts), and lesson access is supported through querying and feedback reporting. Minor gaps include lack of task run retrieval, no lookup by lesson ID, and no cancel/delete operation for task runs, but these can be worked around.
complete_task_runAInspectComplete or update the final status of a Hermes task run with final result, verification evidence, and blockers. Requires x-agent-key and task ownership.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| blockers | No | ||
| task_run_id | Yes | ||
| final_result | No | ||
| verification | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses an authentication/ownership requirement and implies a mutation (complete/update). However, it does not discuss side effects, reversibility, or potential conflicts (e.g., if a task is already finalized), which leaves some transparency gaps for a write 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 a single, well-structured sentence that front-loads the primary action and includes a terse prerequisite. Every word adds value with 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 tool has 5 parameters, nested objects, no output schema, and no annotations. The description explains the core purpose and a few parameters, but does not cover status enum semantics, the structure of verification/blockers, or expected response/errors. It is sufficient for basic invocation but not fully complete for a tool with this complexity.
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 explicitly names 'final result, verification evidence, and blockers' which maps to final_result, verification, and blockers parameters. However, it does not elaborate on the required task_run_id or the status enum values, leaving some parameter meaning implicit.
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: 'Complete or update the final status of a Hermes task run' with specific elements (final result, verification evidence, blockers). This distinguishes it from siblings like start_task_run which initiates a run, and query tools which read data.
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 on when to use the tool (when completing/updating a task run's final status) and notes a prerequisite ('Requires x-agent-key and task ownership'). It does not explicitly mention alternatives or exclusions, but the context is unambiguous enough to differentiate from starting or querying tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_lessonsAInspectSearch Younanix engineering lessons by natural language query. Returns problem summaries with category, confidence, and tags. Full lesson details (root cause, lesson learned, evidence) require the paid agent-query endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language search query | |
| max_results | No | Maximum number of results to return (default 10) |
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 that only summaries are returned, not full details, which is a key behavioral boundary. It does not mention authorization, rate limits, or whether the search is read-only, leaving some transparency gaps for a resource with no annotations.
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 exceptionally concise: two sentences, front-loaded with the action (search) and resource (engineering lessons). The second sentence clarifies the scope without unnecessary elaboration. 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 (2 params, no output schema), the description covers the essential aspects: it states what is searched, what is returned (including specific fields), and highlights a key limitation. It lacks details on pagination or error handling, but those are not critical for a basic 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides; it focuses on output and limitations instead, which is acceptable but not additive.
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: 'Search Younanix engineering lessons by natural language query' and specifies the output as 'problem summaries with category, confidence, and tags.' It also distinguishes itself from a full-details endpoint, making its scope 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 usage for obtaining summaries and explicitly notes that full lesson details require a different (paid) endpoint, providing a clear when-not scenario. However, it does not name sibling tools like query_lessons_full or query_lessons_premium as alternatives, which would have made guidance more actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_lessons_fullBInspectReturns full Younanix Arete V7 lesson envelope (root_cause, lesson_learned, evidence, recency_tier, pattern_strength, etc.). Requires a valid x-agent-key header issued by Younanix admin, otherwise returns an upgrade hint pointing at the x402 paid endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language search query | |
| max_results | No | Maximum number of results (default 10, max 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the auth requirement, the 'upgrade hint' fallback, and the returned envelope fields, which is useful behavioral context. However, it doesn't cover other behaviors like pagination, error conditions, or read-only guarantees.
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 action and key return fields, followed by the auth note. Every word earns its place, with no redundancy or padding.
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, return fields, and a key behavioral requirement (auth and fallback), which is sufficient for a 2-param query tool without an output schema. It lacks any explicit comparison to sibling tools, but the core context is present.
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 100%, with both query and max_results fully described in the input schema. The description adds no extra information about parameter usage, so the baseline of 3 applies.
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 returns a full lesson envelope with specific fields like root_cause and lesson_learned, using a specific verb and resource. It implies differentiation from sibling query_lessons tools through the word 'full' and the enumerated fields, but doesn't explicitly name an alternative.
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 mentions an authentication requirement and an upgrade hint, but provides no guidance on when to use this tool versus query_lessons or query_lessons_premium. It doesn't state a preferred use case or exclude any scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_reflectionBInspectRecord the structured self-reflection for a Hermes task run and update the parent run reflection summary. Requires x-agent-key and task ownership.
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | Yes | ||
| evidence | No | ||
| task_run_id | Yes | ||
| lessons_used | No | ||
| what_went_well | No | ||
| sub_agents_used | No | ||
| improvement_next_time | No | ||
| what_failed_or_uncertain | No | ||
| younanix_feedback_action | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important side effect ('update the parent run reflection summary') and an auth requirement ('Requires x-agent-key and task ownership'). Since no annotations are provided, the description carries the burden, but it omits details such as whether the update is an append or overwrite, idempotency, or failure behavior.
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 concise sentences, both front-loaded with the core action and the auth requirement. There is no redundant or irrelevant text; every sentence 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 complexity (9 parameters, nested objects, no output schema, no annotations), the description is too sparse. It explains the high-level purpose but fails to clarify how to populate the required fields or what the tool returns/does beyond the parent summary update, making reliable invocation difficult.
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%, and the description adds no explanation of any of the 9 parameters. It does not mention task_run_id, outcome, or the semantic meaning of fields like evidence, lessons_used, or younanix_feedback_action, leaving agents to guess from bare property 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 purpose: 'Record the structured self-reflection for a Hermes task run' and 'update the parent run reflection summary.' This specific verb and resource scope distinguish it from sibling tools like record_subagent_trace and report_skill_outcome, though it does not explicitly name alternatives.
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: it is used for Hermes task runs and updates the parent run's reflection summary. It also notes the prerequisite of x-agent-key and task ownership. However, it does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_subagent_traceAInspectRecord a specialist sub-agent brief and output for an existing Hermes task run. Requires x-agent-key and task ownership.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | ||
| output | Yes | ||
| status | No | ||
| confidence | No | ||
| task_run_id | Yes | ||
| subagent_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does mention the authorization requirement ('x-agent-key and task ownership') and the existence constraint, which is useful. However, it does not disclose side effects (e.g., append vs overwrite) or the response shape, leaving some behavioral ambiguity.
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?
Two concise, front-loaded sentences. The first sentence states the action and resource; the second covers prerequisites. Every clause serves a purpose and there is no 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?
The tool has 6 parameters, including two nested objects (brief and output) with no defined structure, and no output schema. The description does not explain the structure of these objects, the allowed values for status/confidence, nor the return behavior. This leaves too many gaps for an agent to confidently invoke the 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 description maps core parameters to its language: 'brief' and 'output' relate directly to the sub-agent's brief and output, 'existing Hermes task run' maps to task_run_id, and 'sub-agent' points to subagent_name. It provides no meaning for status or confidence, and with 0% schema description coverage, this partial compensation is notable but incomplete.
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+resource: 'Record a specialist sub-agent brief and output for an existing Hermes task run.' This clearly states the tool's function and distinguishes it from sibling tools like record_reflection or report_skill_outcome by focusing on sub-agent traces.
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: it is for existing task runs and requires x-agent-key and task ownership. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_younanix_usageCInspectRecord a Younanix checkpoint/query used during a Hermes task run and update parent run summaries. Requires x-agent-key and task ownership.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| lesson_ids | No | ||
| access_path | Yes | ||
| plan_impact | No | ||
| task_run_id | Yes | ||
| trigger_reason | Yes | ||
| insufficient_knowledge | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the auth requirement and the side effect of updating parent run summaries, which is additional context. However, it does not disclose whether the operation is reversible, what the response looks like, or other potential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by the authentication requirement. Every word contributes, with 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?
Given the tool's complexity (7 params, no annotations, no output schema), the description is far too sparse. It does not explain return values, expected outcomes, the meaning of 'Younanix checkpoint/query,' or the exact nature of the parent run summary updates, making it insufficient for reliable use.
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 7 parameters with 0% schema description coverage, and the description adds no parameter-specific meaning. Terms like trigger_reason, access_path, lesson_ids, and plan_impact are entirely unexplained, leaving the agent unable to construct valid arguments.
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 records a Younanix checkpoint/query during a Hermes task run and updates parent run summaries. This is a specific verb-plus-resource with a clear effect, though it does not explicitly differentiate from sibling recording tools like record_reflection or record_subagent_trace.
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 only mentions the prerequisite of x-agent-key and task ownership, but provides no guidance on when to use this tool versus alternatives. It lacks any comparative context or scenarios where this tool is preferred over similar recording tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_skill_outcomeAInspectReport the outcome of applying one or more Younanix lessons in production. Used to build the symbiotic feedback loop. Rate-limited to 100 reports per agent per day. Requires x-agent-key.
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | Yes | ||
| lesson_ids | Yes | UUIDs of the lessons applied | |
| skill_name | No | ||
| outcome_evidence | No | ||
| mttr_minutes_observed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a rate limit ('Rate-limited to 100 reports per agent per day') and an auth requirement ('Requires x-agent-key'), which are valuable. However, it does not mention side effects, idempotency, or error behavior.
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 three concise sentences, each adding distinct value: the action, the purpose, and operational constraints. No unnecessary words.
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 5 parameters and no output schema. The description covers the core purpose and key constraints but lacks return value details and fails to differentiate from similar record_* siblings. It is adequate but leaves gaps for a 5-parameter 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 only 20% (only lesson_ids has a description). The description mentions 'lesson_ids' and 'outcome' implicitly but does not explain skill_name, outcome_evidence, or mttr_minutes_observed. It fails to compensate for the low schema coverage.
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 and resource: 'Report the outcome of applying one or more Younanix lessons in production.' This clearly identifies the tool's function and distinguishes it from sibling tools like record_reflection or submit_incident_report.
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 phrase 'Used to build the symbiotic feedback loop' implies a context for use, but the description does not explicitly state when to prefer this tool over alternatives (e.g., record_younanix_usage) or when not to use it. Usage 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.
start_task_runAInspectStart an auditable Hermes task run. Records objective, plan, task graph, autonomy/risk, and initial metadata. Requires x-agent-key.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | ||
| context | No | ||
| metadata | No | ||
| objective | Yes | ||
| task_type | No | ||
| risk_level | No | ||
| task_graph | No | ||
| autonomy_level | No | ||
| sub_agents_used | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the auth requirement and that the tool records objective, plan, task graph, autonomy/risk, and metadata. However, it does not state side effects, return values, or whether the operation is a write/mutation. The word 'Start' implies a state change, but behavioral details beyond recording are absent.
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 exactly three sentences, each earning its place: first states the purpose, second enumerates recorded fields, third notes the auth requirement. It is front-loaded and free of redundancies or unnecessary 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?
With 9 parameters, no output schema, and no annotations, this description is too sparse. It omits key parameters (context, task_type, sub_agents_used) and provides no return value or richer behavioral context. While the basics are covered, an agent would likely need additional information to invoke the tool correctly in all scenarios.
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 mentions objective, plan, task graph, autonomy/risk, and metadata, covering several schema properties. However, context, task_type, and sub_agents_used are not explained, and the description does not clarify the risk_level enum or autonomy_level semantics. Compensation is partial, leaving gaps for several parameters.
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 the specific verb 'Start' with the resource 'auditable Hermes task run', clearly distinguishing it from the sibling tool complete_task_run. It also lists the key fields recorded (objective, plan, task graph, autonomy/risk, metadata), adding concreteness. This is a clear, specific purpose statement.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The verb 'Start' implies usage for initiating task runs, and the requirement for 'x-agent-key' is a prerequisite, but no comparison with sibling tools like record_reflection or complete_task_run is provided. Usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_incident_reportAInspectSubmit a raw incident report from a production system. The report is queued for admin review and synthesis into a permanent Arete lesson. Requires a valid x-agent-key header.
| Name | Required | Description | Default |
|---|---|---|---|
| stack | Yes | ||
| severity | No | ||
| affected_systems | Yes | ||
| incident_summary | Yes | Concise narrative of what happened |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It reveals that reports are queued for admin review and synthesis into a permanent Arete lesson, and requires a valid x-agent-key header, which are key behavioral traits. It doesn't mention reversibility or failure modes, but adds valuable context beyond the tool name.
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 three sentences and front-loaded with the main purpose. Every sentence adds new information: purpose, outcome, and authentication requirement. No redundant words.
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 annotations and output schema, the description provides sufficient high-level context about the tool's role and post-submission flow. However, it doesn't detail parameter usage or expected response, leaving gaps for effective 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?
Only 25% of parameters have schema descriptions, and the tool description doesn't mention any parameter semantics. The description doesn't explain what `stack`, `affected_systems`, or `severity` mean, leaving the agent to rely solely on schema names and the single description for `incident_summary`.
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 submits a raw incident report from a production system, with a specific verb and resource. It distinguishes itself from sibling tools like query_lessons or complete_task_run by focusing on incident report submission.
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 context for when to use the tool: submitting a raw incident report from a production system. It doesn't explicitly rule out alternatives or mention when not to use it, but the context is clear given the distinct purpose and sibling tools.
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!
