KernelScan
Server Details
Linux kernel CVE analyzer: upload a .config, get a CycloneDX VEX report of affecting CVEs.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 10 of 10 tools scored. Lowest: 3.6/5.
Each tool targets a distinct action: product management (create, get, update, list, VEX), CVE operations (search, get), and administrative tasks (whoami, request access, support). No overlapping purposes.
All tools follow a consistent verb_noun snake_case pattern (e.g., create_product, get_cve, list_products, submit_support_report). The naming is predictable and uniform.
10 tools is well-scoped for this service: core CRUD for products (minus delete), CVE search/retrieval, and account/administrative actions. No unnecessary tools.
The surface covers most workflows: product creation, reading, updating, and VEX generation; CVE search and lookup; and account management. However, a delete product tool is missing, and upload of config files is handled externally via HTTP endpoint.
Available Tools
10 toolscreate_productAInspect
Create a new product, run analysis, and return its initial stats.
``config_upload_id`` references a previously-staged .config that the
caller POSTed to ``/api/configs/uploads`` over plain HTTP — the LLM
does NOT emit the config text itself (a real kernel .config is
~100–200 KB and exceeds a single tool-call output budget). Workflow:
1. Caller / wrapper script:
``curl -H "Authorization: Bearer ks_live_..." \
-F "config_file=@.config" \
https://kernelscan.io/api/configs/uploads``
returns ``{config_upload_id, sha256, size_bytes, expires_at}``.
2. Pass that ``config_upload_id`` into this tool.
Uploads are per-user, single-use, and expire 30 minutes after upload.
Same tier gates as POST /api/products: free can't create products at
all, basic is capped at 3 products, pro at 10. ``factor_ids`` are
silently ignored unless the tier allows security factors
(``pro``/``enterprise``). Re-using a product name returns 409.
| Name | Required | Description | Default |
|---|---|---|---|
| arch | Yes | ||
| name | Yes | ||
| factor_ids | No | ||
| description | No | ||
| kernel_version | Yes | ||
| config_upload_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses several behavioral traits: the tool returns initial stats, the config_upload_id is per-user, single-use, and expires in 30 minutes, tier gates affect creation, factor_ids are ignored below pro, and duplicate names return 409. It also warns the LLM not to attempt to generate the config itself, which is a critical limitation. This is highly 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 in the first sentence, then structured into a workflow paragraph and a restrictions paragraph. It is efficient but somewhat verbose due to the necessary detail for config_upload_id. There is no redundant information, but it could be slightly more concise without losing clarity.
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 complexity (6 parameters, no output schema, no annotations), the description covers the critical workflow and tier restrictions thoroughly. However, it fails to describe the return value format ('initial stats' is vague), and it does not specify expected formats for kernel_version, arch, or name. For a tool with no output schema, the description should at least characterize the output. This leaves the agent uncertain about what to expect.
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 explains config_upload_id in detail (workflow, expiration, usage) and mentions that factor_ids are conditionally ignored, but it provides no semantic meaning for arch, name, kernel_version, or description. These parameter names are ambiguous without context (e.g., what kernel_version format is expected?). The description adds value for only one of six parameters, leaving significant gaps.
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 a clear verb+resource combination: 'Create a new product, run analysis, and return its initial stats.' It specifies the action and outcome, and distinguishes this tool from siblings like get_product, update_product, and list_products by being the creation operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow instructions, including that the config must be uploaded separately via HTTP and the LLM must not emit the config text itself. It also details tier-based restrictions (free cannot create, basic capped at 3, pro at 10), that factor_ids are silently ignored on lower tiers, and that re-using a product name yields a 409 error. This gives clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cveAInspect
Fetch a single Linux kernel CVE by ID (e.g. CVE-2024-12345).
No API key required: keyless callers get the public representation of a
CVE, but only for CVEs in the public set (recent high-severity); any
other id returns ``not found``. Free *keyed* callers get a 404 for CVEs
published more than 60 days ago. AI risk-summary / analysis fields are
included for any keyed user on CVEs in the public set, and for pro /
enterprise on every assessed CVE.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description fully accounts for behavior. Discloses access tiers, limitations, and inclusion of risk-summary. Assumed read-only, no destructive hints needed.
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?
Front-loaded with purpose, then details. Somewhat lengthy but every sentence adds value. 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?
Covers access differences and restrictions comprehensively for a single-resource fetch. Lacks output format details, but schema is simple and return values are implied.
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 has 0% description coverage, but description adds clear format guidance for the single 'cve_id' parameter, including example and expectations.
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?
Clearly states it fetches a single Linux kernel CVE by ID, with example format. Distinguishes from 'search_cves' sibling which searches broadly.
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?
Provides detailed guidance on key vs keyless access, time restrictions, and which CVEs are accessible. Implicitly tells when to use (specific CVE ID) but lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_productAInspect
Fetch one product owned by the caller, including the CVE breakdown.
Returns 404 (not 403) if the product belongs to another user, so product existence isn't leaked across accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the 404 vs 403 behavior, adding important privacy context beyond the tool name. However, it lacks details on response format, rate limits, or authentication requirements. With no annotations, more detail would be beneficial.
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, front-loaded sentences with no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool without an output schema, the description covers the core purpose and a key behavioral nuance. It could improve by hinting at the return structure, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by indicating the product_id identifies a product owned by the caller. It does not specify expected format or constraints, but adds basic 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 clearly states the tool fetches a single product owned by the caller and includes a CVE breakdown. It distinguishes from siblings like get_cve and list_products by specifying the scope and content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for the caller's own products, and the 404 behavior signals it cannot be used for other users' products. However, it does not explicitly contrast with alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_vexAInspect
Return the CycloneDX 1.6 VEX document for one of the caller's products.
Reads from the 24h ProductVexCache; if the cache is empty/expired the
next call to ``get_product`` (or the REST endpoint) will regenerate it.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses caching behavior (24h cache, regeneration via get_product). This adds valuable behavioral context beyond the basic purpose.
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 no wasted words. The main purpose is in the first line, and the second provides crucial caching detail. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers purpose and caching but omits output details, error conditions, and prerequisites. Adequate but with clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter. It states 'one of the caller's products' but does not specify format, validation, or how to obtain the product_id. This is minimal added 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 clearly states the tool returns a CycloneDX 1.6 VEX document for a specific product. The verb 'Return' and the specific resource 'CycloneDX 1.6 VEX document' make the purpose unambiguous and distinguish it from siblings like get_product.
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 provide explicit guidance on when to use this tool versus alternatives like get_product or get_cve. It mentions caching behavior but lacks comparison or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsAInspect
List the calling user's products with denormalized analysis stats.
Paid plans only (basic / pro / enterprise). Free callers get a clear upgrade message.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavior: it mentions the upgrade message for free callers and denormalized stats, but does not state read-only nature or other side effects like idempotency.
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 contains no extraneous information. 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 zero parameters and an output schema, the description covers the essential purpose and a key restriction (paid plans). It does not explain 'denormalized analysis stats', but that is likely detailed in the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema, so the description adds no parameter info, which is appropriate. The description does not need to compensate for any missing parameter details.
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 lists the calling user's products with denormalized analysis stats, distinguishing it from siblings like get_product (single product) and create_product (creation).
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 specifies that the tool is for paid plans only and that free callers get an upgrade message, providing clear context. However, it does not explicitly mention when not to use or suggest sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_accessAInspect
Request an invitation to KernelScan from inside MCP (no API key needed).
Use this when a keyless caller wants the full service. It records an
invitation request and emails a confirmation; an admin reviews it and,
if approved, sends an invitation code. This tool does NOT create an
account or mint an API key — you finish signup (including accepting the
terms) on the website after you receive the invitation.
``email`` is required. ``name`` and ``reason`` are optional context for
the reviewer. The response is identical whether or not the email is
already known, so it never reveals account state.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| Yes | |||
| reason | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool records an invitation request, sends confirmation email, and that the response is identical for known/unknown emails to prevent state leakage. It also outlines the admin review process. No destructive actions implied, and no contradictions.
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: opens with the core purpose, then usage guidance, then what it does not do, parameter details, and behavior. Each sentence adds value without redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers all critical aspects: purpose, when to use, parameter meanings, behavioral transparency, and response privacy. However, it lacks details about the exact response structure (though it mentions the response is identical). For a simple request tool, this is nearly complete, but missing a brief note on what the response looks like is a minor gap.
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 has 0% description coverage, so the description must compensate. It explicitly states email is required and that name and reason are optional context for the reviewer. This adds meaning beyond the raw schema, clarifying the purpose of optional parameters. However, it does not provide format details or constraints beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it requests an invitation to KernelScan from inside MCP for keyless callers wanting the full service. It distinguishes itself from account creation or API key minting, which are handled later on the website. The verb 'Request an invitation' is specific and the resource is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when a keyless caller wants the full service.' It describes the process (records request, emails confirmation, admin approval) and clarifies what the tool does NOT do (create account or mint API key). It also explains the response behavior to avoid revealing account state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cvesAInspect
Search Linux kernel CVEs.
No API key required: keyless callers get the free public tier — recent
high-severity Linux kernel CVEs (capped at 25 results). Free *keyed*
callers see only CVEs published in the last 60 days; basic+ keyed
callers get the full corpus.
``query`` matches against CVE id and description (case-insensitive).
``severity`` filters by effective severity (``critical``/``high``/``medium``/``low``).
``cvss_min`` filters by effective CVSS score.
``published_after`` (ISO 8601) returns only CVEs newer than that date.
Returns up to ``limit`` (max 100) CVEs, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| cvss_min | No | ||
| severity | No | ||
| published_after | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: result limits per tier, filtering behavior (case-insensitive, effective severity/CVSS), sorting (newest first), and the need for API keys for full access. This goes beyond minimal requirements.
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 opening statement followed by bullet points for each feature. Every sentence provides valuable information without 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 no output schema, the description still covers what is returned (up to limit CVEs, newest first) and explains tier-based differences. It is complete enough for an agent to understand the tool's capabilities and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explains every parameter (query, severity, cvss_min, published_after, limit) with details on format, matching behavior, and constraints. This fully compensates for the lack of schema-level descriptions.
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 Linux kernel CVEs,' which clearly states the tool's purpose. It further details filtering by query, severity, CVSS score, and date, distinguishing it from sibling tools like get_cve (which retrieves a single CVE).
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, including access tiers (keyless, keyed) and result caps. It does not explicitly mention alternatives or when not to use, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_support_reportAInspect
Send a support / dispute report to KernelScan staff.
Use this when an automated CVE or factor assessment looks wrong, or
when you need to hand human-needed context back to the team. The
caller's API-key user is attached automatically (id, email, plan)
so support can look the account up.
``category`` should be one of:
- ``cve_assessment`` — wrong AI verdict / CVSS / CWE on a CVE
- ``factor_assessment`` — wrong factor verdict for a product
- ``bug`` — broken behavior in the API or UI
- ``other`` — anything else
``cve_id`` / ``product_id`` / ``assessment_id`` are optional but
recommended — they let support jump straight to the relevant row.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | No | ||
| message | Yes | ||
| subject | Yes | ||
| category | Yes | ||
| product_id | No | ||
| assessment_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the caller's API key user is attached automatically (id, email, plan), which is a useful behavioral trait. However, it doesn't mention side effects, rate limits, or response behavior. Given the non-destructive nature, the disclosure is adequate but not exhaustive.
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. It uses a brief introductory sentence followed by bullet points for category and optional IDs. Every sentence adds value without 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 (3 required) and no output schema. The description explains the category and optional IDs but lacks detail on the 'subject' and 'message' parameters, and does not describe the response format (e.g., success confirmation). For a simple action, it is mostly complete but could mention expected output or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does so by explaining the 'category' parameter with enumerated options and describing the purpose of optional IDs (cve_id, product_id, assessment_id). However, 'subject' and 'message' are not elaborated, but their purpose is somewhat self-evident.
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: sending a support/dispute report to KernelScan staff. The verb 'send' and resource 'support report' are specific, and the description distinguishes it from sibling tools by specifying when to use it (wrong automated assessments, need to hand context).
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 outlines when to use the tool (when an automated CVE or factor assessment looks wrong, or to hand human-needed context). While it doesn't explicitly state when not to use it, the context is clear enough. It doesn't mention alternative tools for non-support scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_productAInspect
Update a product owned by the caller. Re-runs analysis if the kernel_version, arch, or referenced .config changed.
To change the .config, first POST the new file to
``/api/configs/uploads`` (see ``create_product`` for the curl recipe)
and pass the returned ``config_upload_id`` here. Leave
``config_upload_id`` as ``None`` to keep the existing .config.
``factor_ids=None`` leaves factor selections untouched; an empty
list clears them. Same tier gates as PUT /api/products/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| arch | No | ||
| name | No | ||
| factor_ids | No | ||
| product_id | Yes | ||
| description | No | ||
| kernel_version | No | ||
| config_upload_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully shoulder behavioral transparency. It discloses that re-analysis is triggered on changes to kernel_version, arch, or .config. Also references tier gates. However, missing details on rate limits, rollback, 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?
Description is concise with front-loaded purpose. The curl reference adds necessary context without being overly verbose. A minor reduction in niche detail could improve, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 params, no annotations, and no output schema, the description provides key behavioral context (re-analysis trigger, config upload process, factor_ids handling). Lacks error scenarios or response format, but adequate for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must supplement. It explains config_upload_id (upload process) and factor_ids (None vs empty list). Does not explain arch, name, description, kernel_version individually, but connects kernel_version to re-analysis. Adds value 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 clearly states the tool's purpose: 'Update a product owned by the caller.' It specifies the resource (product) and the action (update), and distinguishes from sibling like 'create_product' by implying mutation rather than creation.
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?
Provides explicit when-to-use context ('Update a product') and details on updating .config using 'create_product' recipe. Mentions 'Same tier gates' hinting at authorization. Does not explicitly state when not to use, but gives clear usage flow for parameter handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiAInspect
Return the caller's identity, plan, and quota state.
Works without an API key: keyless callers get a lightweight public-tier
payload (no account) describing how to request access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It transparently explains that keyless callers receive a lightweight public-tier payload, which is an important behavioral trait. It does not mention side effects, but as a read-only introspection tool, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and every sentence adds value. It is concise and well-structured for an AI agent to quickly grasp the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could be more complete by listing the fields returned (e.g., identity details, plan name, quota numbers). While the key behavioral difference is covered, the agent lacks specifics about the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% (vacuously). The description adds context by distinguishing behavior based on authentication, which goes beyond the empty schema. This provides value beyond the structured fields.
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 the caller's identity, plan, and quota state. This is a specific verb ('Return') and resource ('caller's identity, plan, and quota state'). It distinguishes from sibling tools like create_product or get_cve, which deal with products and CVEs.
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 mentions that it works without an API key, providing key usage context. However, it does not state when not to use it or mention alternative tools for similar purposes, but the context of sibling tools makes the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!