agent-kernel-mcp

by fr4iser90

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools clearly target distinct resources and actions, such as projects, assignments, runs, and health. The only mild ambiguity is between ak_nudge and ak_scheduler_tick, since both can trigger executor work, but their descriptions clarify the difference.
Naming Consistency3/5
All tools share a consistent ak_ prefix and snake_case style, which helps readability. However, the set mixes verb_noun names like ak_list_projects with noun-only names like ak_health, ak_attention, and ak_me, so the pattern is not fully uniform.
Tool Count5/5
12 tools is well within the ideal range and each tool serves a distinct operational area of the agent-kernel domain. The count feels appropriately scoped without redundancy or obvious bloat.
Completeness3/5
The surface covers listing and reading projects, assignments, and runs, plus scheduler and executor actions. Notable gaps include no way to update executor settings, cancel or retry runs, or get a single assignment by id, which limits full control-plane coverage.
Average 3.4/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 only states that the tool surfaces the current user and setup gaps, but does not explain whether it performs checks, what authentication is required, what 'setup gaps' means, or what a successful response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, containing no filler words. However, it is a fragment rather than a structured sentence, which slightly reduces clarity and usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has no parameters and low complexity, there is no output schema or annotations to compensate for the vague description. The meaning of 'setup gaps' and the exact return information are left undefined, so an agent has incomplete context for invoking the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter documentation is needed. The schema fully covers the empty parameter set, and the description is not required to add extra parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase names a clear resource: the current authenticated user and setup gaps. It lacks an explicit verb, but the intent to return or report these items is evident. It does not explicitly distinguish itself from sibling tools like ak_health, though the resource is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not state when to call this tool instead of ak_health or other siblings, nor does it mention any prerequisites or setup checks it performs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden of behavioral disclosure. It only says 'Live-test' without explaining potential side effects, expected outcomes, safety, or what the test does to the configured executor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler; the key action and target are front-loaded. It earns its place, though it remains somewhat sparse rather than richly informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool, the description is enough to identify the intended action, but it leaves important context unstated: what 'live-test' actually entails, what a successful result looks like, and whether invoking it has side effects. The low complexity makes this acceptable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and contains no parameters, so there is nothing for the description to clarify beyond what the schema already states. With zero parameters, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Live-test') and resource ('configured executor (DSH)') with a source ('from the kernel'), making the action identifiable. It does not explicitly contrast itself with siblings like ak_health, but the resource and action are clear enough for basic differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ak_health or ak_executor_settings. 'Live-test' implies a diagnostic context, but no explicit conditions, exclusions, or preferred scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. 'List' implies a read operation, but the description does not mention output format, ordering, pagination, or whether any filtering is possible. For a tool with no annotations, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the verb and resource, and for a zero-parameter list tool, this is appropriately sized and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity with no parameters and no output schema, so the description is almost sufficient. However, it does not explain what an 'attention item' is, what the returned data looks like, or any observable behavior beyond listing. Given the lack of annotations and output schema, the description leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%, so there are no parameter semantics for the description to add. The baseline of 4 applies because the tool has no parameters and the description does not mislead about them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('List') and resource ('observability attention items from agent-kernel'), which clearly distinguishes this from sibling list tools like ak_list_projects and ak_list_runs. However, 'attention items' is somewhat domain-specific and not elaborated, preventing a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the description implies it should be used to list observability attention items, it does not mention how this differs from other list tools or when this is preferred. Sibling tools exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get') but does not disclose return format, error behavior for missing projects, permissions, rate limits, or whether the response is a full project object or a summary. This is thin for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word earns its place, and the verb and object are immediately clear. This is appropriately concise for such a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must stand alone. It names the operation and the required parameter but omits return value shape, not-found behavior, and when to prefer this over list operations. For an agent selecting and invoking the tool, this is minimally sufficient but leaves important ambiguities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description coverage in the schema is 0%, so the description must compensate for the single parameter. 'By id' clarifies that projectId is the lookup key, but the schema property name already suggests this. The description does not explain the format of the ID, how to obtain it, or any constraints beyond the schema's required flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get'), a specific resource ('one project'), and the selection mechanism ('by id'). This distinguishes it from the sibling ak_list_projects, which presumably returns multiple projects. However, it could more explicitly contrast itself with the list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by id' implies this tool should be used when a specific project identifier is known, versus listing projects. But there is no explicit guidance about when to choose this over ak_list_projects or any other sibling, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It indicates an action that processes due items, but it does not disclose side effects, whether nudges are actually sent, whether the action mutates state, or what the return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tight sentence that front-loads the action and uses a parenthetical to express scope. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter trigger tool, this is minimally viable: the agent knows what action to expect. However, with no output schema and no annotations, return values, side effects, and failure behavior are absent, leaving meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema imposes no burden on the agent. The baseline of 4 applies because there is nothing for the description to clarify about arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and resource ('one agent-kernel scheduler tick') and adds a clarifying parenthetical about processing due assignments/nudges. It is clear about what the tool does, though it does not explicitly contrast with sibling tools like ak_nudge or ak_list_assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to invoke this tool versus alternatives. The description says it runs a scheduler tick, but it does not explain scenarios where this is needed or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description itself must carry the behavioral disclosure burden. It simply says 'check health' without stating that the operation is read-only, what a healthy or unhealthy response looks like, whether authentication is required, or what side effects (if any) occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that front-loads the action and resource with no wasted words. For a zero-parameter tool, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, no nested objects), the description is minimally adequate for recognizing the tool's purpose. However, with no output schema and no annotations, the agent is not told what the health check returns or how to interpret the result, leaving a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics because there are none, and the schema is empty and fully self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('check') and a clear resource ('agent-kernel API health'), which is distinct from the sibling project, assignment, run, and executor tools. It is not a 5 because 'health' is somewhat generic and does not specify whether this is a liveness, readiness, or dependency check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the name and description — run it to verify API health — but there is no explicit guidance on when to call it (e.g., before dependent operations, after failures) or exclusions. No alternative health-check sibling exists, so there is no comparison to make.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the basic read-only intent ('list') but does not disclose ordering, recency bounds, default limits, result shape, or any filtering behavior. It is minimal rather than misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
'List recent runs.' is three words with no filler, fully front-loaded, and appropriately sized for a zero-parameter tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation, the description is technically sufficient to invoke, but 'recent' is vague and there is no indication of output shape, ordering, or limits. With no output schema and no annotations, important contextual information is left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero properties and 100% coverage, so the absence of parameters is already fully clear. The description adds no parameter detail, but none is needed; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('runs'), so an agent can tell this is a listing operation rather than a retrieval or mutation. It is implicitly distinguished from siblings like ak_get_run (list vs. get) and ak_list_projects/ak_list_assignments (runs vs. other entities), though 'recent' is left undefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit 'when to use' or 'when not to use' guidance is given, and no alternative tools are mentioned. The intended use is implied by the description: call this when you need a list of recent runs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the core behavioral action: starting or continuing an executor run, and contrasts it with ad-hoc autonomy. However, with no annotations provided, the description does not address side effects, idempotency, permission requirements, or failure behavior, leaving some transparency burden unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the usage guidance is compactly packed into the second sentence. The unexplained term 'DSH autonomy' slightly reduces clarity, but the structure is otherwise efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter control action, the description covers what the tool does and when to prefer it. It omits return-value behavior and prerequisites for the control-plane-owned schedule, so the context is adequate but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for parameter meaning. 'Nudge an assignment' implies assignmentId identifies the assignment to nudge, but it provides no format details, constraints, or guidance on how the parameter affects the run beyond that basic inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb-resource pair ('Nudge an assignment') and explains the effect ('kernel starts / continues an executor run'). The 'prefer this over...' clause hints at its distinct role, but it does not explicitly name a sibling such as ak_scheduler_tick or ak_test_executor, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit preference condition ('Prefer this over ad-hoc DSH autonomy when the control plane owns the schedule'), which tells an agent when to choose it. It lacks a fuller set of when-not conditions or named alternatives, so it is not maximally explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 behavioral disclosure. It does convey that the operation is scoped to the current user and that it lists data, but it does not mention response format, ordering, pagination, or authorization context. These gaps are modest for a simple read-only list, but still present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single unambiguous sentence with no filler. Every word earns its place, and the core action and scope are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema, so the description is the only explicit source of information. It states what the tool does and for whom, but it does not explain what an assignment is, what the response looks like, or when to prefer this tool over siblings. This is acceptable for a very simple invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics for the description to clarify. The input schema is trivially complete, and the baseline for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a distinct resource ('assignments'), and a clear scope ('for the current user'). It is easily distinguished from sibling tools like ak_list_projects and ak_list_runs because it names a different resource without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The description does not mention situations where another tool would be more appropriate, nor does it reference any sibling tool for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 behavioral disclosure. 'List' strongly implies a read-only operation, but there is no mention of pagination, sorting, return shape, or whether the result set is limited. The description is not misleading but is too sparse to provide meaningful behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states the action and scope without waste. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 0-parameter listing tool, the description covers the essential purpose and user scope. However, with no output schema and no annotations, it does not explain what information is returned or whether pagination applies, leaving some ambiguity about the result shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has 100% coverage, so there is no parameter meaning for the description to add. As a baseline for a 0-parameter tool, this is handled appropriately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('catalog projects'), and narrows scope to 'the current user.' This clearly distinguishes it from sibling tools like ak_get_project (singular) and ak_list_assignments (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing projects belonging to the current user, but it does not explicitly state when to use it instead of alternatives such as ak_get_project for a single project. Usage context is present but exclusions and alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explicitly discloses that the operation is read-only and that secrets are redacted by the API, which is meaningful behavioral context beyond the tool name. It does not detail response shape or error behavior, but for a zero-parameter read operation this is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It communicates the operation, scope, and an important behavioral caveat in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema and no annotations, the description covers the core information an agent needs: what it reads, for whom, and a key response behavior. Slightly more detail about the returned settings structure would push it to complete, but it is not essential for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. Baseline 4 applies; the description appropriately avoids inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Read'), a precise resource ('current user executor settings'), and a useful caveat (secrets redacted by API). It clearly distinguishes this from sibling project/run/assignment tools without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any mention of when it should not be used. The purpose is implied by the name and description, but exclusions or pointers to siblings are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. 'Get' conveys a non-mutating read and 'one' conveys singleton cardinality, but it does not disclose not-found behavior, required permissions, or what the returned run looks like. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. Every word contributes to the tool's purpose and invocation condition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool, 'Get one run by id' plus the schema's required runId is sufficient for an agent to invoke it correctly. It does not cover error cases or return details, but the low complexity and clear sibling context make those gaps minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required string parameter, runId, with 0% description coverage. The phrase 'by id' maps runId to the run's identifier, adding a small amount of meaning, but it does not explain format, origin, or lookup semantics beyond what the parameter name already implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a concrete resource ('run'), and a selection criterion ('by id'), so an agent can distinguish this from ak_list_runs (all runs) and ak_get_project (another entity). The one-sentence definition fully identifies the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Get one run by id' clearly establishes the condition for using this tool: the agent has a runId and wants a single run. It does not explicitly contrast with ak_list_runs, but 'one' versus the sibling name 'list' makes the intended context apparent without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![agent-kernel-mcp MCP server](https://glama.ai/mcp/servers/fr4iser90/agent-kernel-mcp/badges/card.svg)](https://glama.ai/mcp/servers/fr4iser90/agent-kernel-mcp)

Score Badge

Copy to your README.md:

[![agent-kernel-mcp MCP server](https://glama.ai/mcp/servers/fr4iser90/agent-kernel-mcp/badges/score.svg)](https://glama.ai/mcp/servers/fr4iser90/agent-kernel-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fr4iser90/agent-kernel-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server