Read-only KAI network overview, standards, fees, public terms, and developer onboarding.
Scored across 8 tools
Most tools target distinct public-information topics, but fee_schedule and founding_trial_terms overlap around fees, and kai_overview versus developer_onboarding may blur for broad onboarding questions. Descriptions provide enough context to separate them, so only minor confusion remains.
All tool names use consistent snake_case noun phrases (e.g. kai_overview, fee_schedule, public_pages). The style is predictable throughout, and the lack of a verb prefix is appropriate for a read-only public-information server.
Eight tools is well within the ideal 3–15 range and each covers a distinct public-facing topic. The set is not bloated or thin for a public information surface.
The tools cover core public areas: network overview, E2R, KME, fees, trial terms, onboarding, page index, and standards. Minor gaps may exist for general FAQ, contact, or legal terms, but the surface is largely complete for public disclosure.
Public onboarding guidance for developers, including the separation between account, membership, and commercial authorization.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety and repeatability are covered. The description adds only that the material is public guidance and what topics it spans; no hints about return shape or depth of content.
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?
One compact sentence with no filler, and the most important qualifier ('public onboarding guidance for developers') is front-loaded. It is slightly information-dense as a run-on but nothing is wasted.
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 zero-parameter read tool with full annotation coverage this is close to adequate, but with no output schema the description could say a little more about what the guidance returns or how it is organized, so the agent knows 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?
The tool takes zero parameters, which is the baseline case where the schema itself is trivially complete. No parameter explanation is needed or expected.
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?
States a specific resource (public developer onboarding guidance) and even enumerates the covered topics: account, membership, and commercial authorization separation. An agent can tell it is a documentation/guidance fetch, but the description does not distinguish it from sibling guidance tools such as public_pages or supported_standards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given, and no alternative is named. With several sibling overview/guidance tools in the namespace, the agent has to guess whether this or public_pages is the right entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public purpose of E2R, the evidence-backed experience and reputation protocol. Scoring internals are not public.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds one real piece of context — that scoring internals are intentionally withheld — but says nothing about the shape or volume of what is returned, so it only modestly exceeds the annotation bar.
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 short sentences, no filler, with the subject (what E2R is) front-loaded and the scope caveat trailing. 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?
For a parameterless, read-only informational tool with annotations covering the safety profile, the description conveys what it covers and what it will not reveal. It could be slightly more explicit that the output is a static reference document, but nothing critical to invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and has no parameters to document, so the baseline is 4. Nothing in the description conflicts with or needs to compensate for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource and its scope (the public purpose of the E2R protocol) and even expands the acronym into 'evidence-backed experience and reputation protocol,' which tells an agent the domain. It does not, however, distinguish itself from sibling overview tools such as kai_overview or kme_overview.
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?
'Public purpose' plus 'scoring internals are not public' implies this is an introductory read and explicitly rules out one use case (extracting scoring internals). No alternative tool is named for agents who need scoring details, so usage is only partially guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public graduated KAI platform fee schedule, including what the fees do and do not cover.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds content-scope context (fees and what they do/don't cover) but says nothing about the return format or how the schedule is presented. With annotations carrying the behavioral burden, 3 is appropriate.
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?
A single front-loaded sentence with no filler or redundant restatement of the title. It is efficient, though the final clause is slightly vague about what 'do and do not cover' concretely means.
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 zero-parameter static content tool with no output schema, the description is serviceable but thin: it does not state that it returns the published schedule text or point to any related sibling for comparison terms. It is adequate for invoking the tool but leaves an agent with only inferential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description has no parameter semantics to explain. The 4 baseline for parameterless tools applies; there is no gap to compensate for.
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 names a specific resource (the KAI platform fee schedule) and qualifies it as public and graduated, so the agent can distinguish it from overview siblings like kai_overview or kme_overview. It stops short of explicitly signalling which sibling to prefer, so it lands at 4 rather than 5.
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?
There is no explicit when-to-use or when-not-to-use statement and no named alternative. The purpose implies the usage context (answer pricing questions), which is the minimum-viable level of guidance for a static, zero-parameter content tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historical compatibility endpoint. The 30-day fee waiver is discontinued; standard graduated KAI fees apply immediately to qualifying commerce.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and a closed world, so the safety profile is covered. The description earns credit for disclosing the deprecation/backwards-compatibility status and the fact that fees now apply immediately, but it says nothing about the response payload or whether the endpoint is slated for removal.
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 short sentences with no filler, and the deprecation status is front-loaded in the first clause. It is efficiently sized, though the second sentence compresses two distinct claims (waiver discontinued, fees immediate) into one.
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 no-parameter informational endpoint with no output schema, the description should say what the caller gets back and whether it is safe to skip. It covers the business state but omits the return content and any deprecation timeline, leaving a meaningful 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?
The tool takes zero parameters, so the baseline is 4; there is no parameter meaning for the description to add or omit. Nothing in the description conflicts with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as the discontinued founding-trial terms and frames it as a 'historical compatibility endpoint,' which tells the agent it is about legacy trial terms. However, it never states what the tool actually returns (terms text? fee table? deprecation notice), so the purpose is only partially pinned down.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance and no alternatives named, despite obvious siblings (fee_schedule for current fees, kai_overview). The phrase 'standard graduated KAI fees apply immediately' implies the trial path is dead, but the agent is left to infer that it should consult fee_schedule instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public overview of the KAI network: what it is, what it does, who it is for, and its public trust principles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is fully covered externally. The description adds no behavioral context beyond that (no note on caching, staleness, or that this is a static/public document), which is acceptable for a zero-parameter read tool but adds no value of its own.
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?
One sentence, front-loaded with the resource type and then the payload contents. No filler, nothing repeated from the title or schema.
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 no-param, no-output-schema informational tool the description is essentially sufficient: an agent knows what it will read. The only real gap is the absence of routing guidance among the many sibling overview tools, which is a usage concern rather than a completeness one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so per the rubric this is the baseline of 4. The schema is 100% covered and there is nothing for the description to explain.
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?
States a clear resource (the KAI network) and enumerates the content an agent will get: what it is, what it does, who it is for, trust principles. That is specific enough to distinguish it from most tools. However, it does nothing to separate itself from the near-identical overview siblings such as e2r_overview and kme_overview.
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?
There is no explicit when-to-use guidance and no mention of alternatives, despite four other overview/documentation siblings in the same namespace. The agent must infer that this is the entry-point read for KAI-specific orientation; nothing in the text confirms or excludes that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public description of KME, one commercial venue within the broader KAI network, and its public commercial participation rules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safe, deterministic, closed-world read profile is established without the description. The description adds that the content is 'public,' implying no authentication is needed, but discloses nothing further about response shape, size, or freshness.
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?
A single front-loaded sentence with no filler, and the subject (KME) leads. The only quibble is the repetition of 'public' and a slightly dense compound clause, but nothing needs trimming.
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 no parameters and no output schema, the description carries the full burden of explaining what comes back, and it only sketches this ('description' plus 'participation rules'). For a static documentation-style tool the definition is minimally adequate but leaves the agent guessing at the actual return content and formatting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is effectively self-describing (additionalProperties: false, empty properties), so there is no parameter semantics for the description to add. The baseline for a 0-parameter tool is 4.
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 names a specific resource (KME) and enumerates its content: a public description plus public commercial participation rules. It also positions KME as 'one commercial venue within the broader KAI network,' which implicitly distinguishes it from the network-level overview tools. It stops short of explicitly contrasting itself with its obvious sibling, kai_overview.
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?
There is no statement of when to call this tool, no prerequisites, and no named alternative. The phrase 'within the broader KAI network' hints at a relationship to kai_overview and e2r_overview, but the description never tells an agent to prefer one over the other. Comparable to the MID calibration case, which scored 2 for the same absence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List of the public KAI website pages and their paths. Member and owner areas are not included.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety and determinism profile is covered by structured data. The description adds the scope restriction about member/owner areas, but says nothing about pagination, rate limits or result shape. With annotations doing the heavy lifting, this is adequate but thin.
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 short sentences, zero filler, with the resource stated before the scope caveat. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with no output schema, the description covers what is enumerated and explicitly bounds the scope. The only minor gap is that the exact return structure (paths only, or additional metadata) is left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the baseline there is nothing for the description to clarify; the schema and description are consistent. No misleading parameter information is present.
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?
States a specific verb (list) plus the resource (public KAI website pages) and even the returned field (paths), which is more than a tautology. It does not name any sibling tool, but its scope is distinct enough from the overview/terms/schedule siblings that an agent can select it.
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 exclusion 'Member and owner areas are not included' tells the agent when this tool is NOT the right source, which is useful implied guidance. However, it names no alternative tool for those areas and gives no other use conditions, so usage is only partially specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public list of standards KAI works alongside where compatible and available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safety and determinism profile is covered. The description adds only the word 'Public' (implying no authentication) and the hint that coverage may be partial ('where compatible and available'), which is modest context beyond the 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?
It is a single short sentence with no padding, which is good, but it reads as a fragment rather than a front-loaded statement of purpose, and 'where compatible and available' adds hedging rather than information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description should at least characterize what the list contains so an agent knows what to expect back. It hints at 'standards' but never clarifies the return content, leaving a gap that the absent output schema cannot fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter semantics are missing.
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?
It conveys a specific resource (standards KAI works alongside), and 'Public list' implies a read-only listing. However, the qualifier 'where compatible and available' muddies what the tool actually returns, and there is no differentiation from any of the eight sibling 'overview/info' tools. Purpose is discernible but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus sibling reference tools like kai_overview or developer_onboarding, and no exclusions or prerequisites. The agent is left to infer everything about appropriate invocation from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
developer_onboardinge2r_overviewfee_schedulefounding_trial_termskai_overviewkme_overviewpublic_pagessupported_standardsRead-only Autonomy capability, schema, status and pricing discovery. Paid execution remains paused.
Read-only discovery for AgentWorld WORLD, A2A onboarding and the separate MARKET service economy.
Keyless docs/discovery. RPC follows chain policy; indexed data and account tools need an API key.
Read-only BlockReq docs, network catalog, and JSON-RPC calls across EVM chains
Add one secure layer between your agents and this server.