Kanbai — public project templates and SOPs

Server Details

Read-only access to Kanbai's public project templates and SOPs. Public, no authentication.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.9% over 22 days
Last Tested: 2026-09-29 02:05
Transport: Streamable HTTP · MCP 2025-03-26
URL

TDQS

A4.4/5.0

Scored 2026-09-24 13:55 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: list vs get for two separate resource types (SOPs and templates). No overlapping functionality exists, and even the list and get pairs are unambiguous due to the resource names.

Naming Consistency5/5

All tools follow a consistent kanbai_<verb>_<noun> pattern (get_sop, get_template, list_sops, list_templates). The naming convention is uniform and predictable, with no mixing of styles.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of exposing public templates and SOPs. Each tool serves a necessary function (listing and retrieving each resource type), and the count is appropriately lean.

Completeness5/5

The tool surface is complete for a read-only public reference server. It provides list and get operations for both resource types, covering the entire lifecycle available to agents. No missing CRUD operations are expected since content is not user-managed.

Available Tools

4 tools

kanbai_get_sopA

Read-onlyIdempotent

Inspect

Get one public SOP by numeric id, including its full content.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	SOP id.

Output Schema

ParametersJSON Schema

Name	Required	Description
`sop`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond annotations by specifying that only public SOPs are accessible and that the full content is returned, which informs the agent about scope and response expectations.

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 that conveys the resource, the scope ('public'), the lookup method ('numeric id'), and the response behavior ('full content') with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only getter with a full output schema and strong annotations, the description is complete. It tells the agent exactly what will be fetched and under what scope, and the output schema covers return-value details.

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?

Schema description coverage is 100%, with the id parameter already described as 'SOP id' and constrained to positive integers. The description's 'numeric id' mildly reinforces this but does not add substantial new meaning beyond the schema.

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 clearly states a specific verb and resource: 'Get one public SOP by numeric id'. It also differentiates from sibling tools by specifying 'one' SOP rather than a list, and by naming SOP rather than template, so an agent can distinguish it from list_sops and get_template.

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?

The description gives clear context: use this tool when fetching a single public SOP by its numeric id, including full content. It does not explicitly name alternatives or state when not to use it, but the singular 'one' versus the sibling list tools provides enough implicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kanbai_get_templateA

Read-onlyIdempotent

Inspect

Get one public project template by numeric id, including its ordered task list (title, description, status/priority defaults, offset and duration in days).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Template id.

Output Schema

ParametersJSON Schema

Name	Required	Description
`template`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description still adds useful behavioral scope beyond that: it commits to the 'public' template space and describes the shape of the returned content (ordered tasks with defaults and offsets), which tells the agent what a successful call yields.

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 sentence, front-loaded with the action and identifier and then the payload, with no filler. Every clause carries information.

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?

An output schema exists, so return-value documentation is not strictly required, and the description's brief return summary is a bonus. For such a simple read tool the coverage is close to complete, with only failure behavior for a nonexistent or non-public id left unaddressed.

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?

Schema description coverage is 100% and the single 'id' parameter is fully documented ('Template id.', exclusiveMinimum 0). The description only reinforces the type with 'numeric id', adding little beyond the schema, which matches the baseline for fully covered parameters.

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?

States a specific verb and resource ('Get one public project template by numeric id') and adds the scope qualifier 'public' plus the returned content. The singular 'one' plus the id-keyed lookup clearly separates it from the sibling kanbai_list_templates, so an agent can route without opening a schema.

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?

Usage is implied: fetch this when you already hold a template id, rather than when enumerating templates. However, the description never explicitly contrasts itself with kanbai_list_templates or states what to do when the id is unknown, so the guidance remains inferential.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kanbai_list_sopsA

Read-onlyIdempotent

Inspect

List Kanbai's public standard operating procedures (title, category).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`sops`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: it restricts results to 'public' SOPs and specifies the output fields (title, category). This supplements the annotation-provided safety profile without contradicting it.

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 contributes meaning: the verb, the resource, the qualifier 'public', and the output fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only listing operation with an output schema and comprehensive annotations, the description fully covers scope and return content. Nothing an agent needs to decide whether to invoke this tool is missing.

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 schema description coverage is 100%, so the baseline is 4. The description does not need to explain parameters; the parenthetical mentioning title and category gives useful context about the output shape.

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'), identifies the resource ('Kanbai's public standard operating procedures'), and states the return scope (title, category). It clearly distinguishes from sibling tools like kanbai_list_templates and kanbai_get_sop by focusing on SOPs rather than templates or individual retrieval.

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?

The description clearly communicates that this tool enumerates public SOPs and lists their title and category, implying it is the listing counterpart to kanbai_get_sop and distinct from kanbai_list_templates. It gives clear context but does not explicitly state when not to use it or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kanbai_list_templatesA

Read-onlyIdempotent

Inspect

List Kanbai's public project templates (name, description, task count). Templates are the reusable task graphs new projects are instantiated from — public reference content, not a customer's live project data.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`templates`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description only needs to add context beyond that. It usefully explains that templates are reusable task graphs and public reference content, not customer data. This adds meaningful behavioral scope without contradicting 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two focused sentences. The first sentence conveys the core action and expected output fields, while the second adds valuable context about what templates are and what they are not. There is no filler or repetition of schema or annotation data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless list tool with a provided output schema and safety annotations, the description is complete. It identifies the resource, the scope (public reference content), and the distinction from customer live data, giving an agent enough to invoke it correctly.

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 input schema is empty, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because no parameter documentation burden exists.

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 specific resource ('Kanbai's public project templates'), and the return content ('name, description, task count'). It also distinguishes this tool from customer-data tools by emphasizing these are public reference templates, not live project data. This clearly separates it from siblings like kanbai_list_sops and kanbai_get_template.

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?

The description provides clear context: this lists reusable public templates, not customer live project data, which tells an agent when it is appropriate to use. It does not explicitly name alternatives like 'use kanbai_get_template for a single template's full details,' but the context is strong enough to guide selection among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 24, 2026
- Removedget_membership_offer
1 tool updateSep 12, 2026
- Changedkanbai_get_template10 fields changed
  - addedOutput schema / properties / template / properties / tasks / items / properties / duration_days / anyOf
```
Added value: +[
+  {
+    "maximum": 9007199254740991,
+    "minimum": -9007199254740991,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / template / properties / tasks / items / properties / duration_days / maximum
```
Removed value: -9007199254740991
```
  - removedOutput schema / properties / template / properties / tasks / items / properties / duration_days / minimum
```
Removed value: --9007199254740991
```
  - removedOutput schema / properties / template / properties / tasks / items / properties / duration_days / type
```
Removed value: -"integer"
```
  - addedOutput schema / properties / template / properties / tasks / items / properties / offset_days / anyOf
```
Added value: +[
+  {
+    "maximum": 9007199254740991,
+    "minimum": -9007199254740991,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / template / properties / tasks / items / properties / offset_days / maximum
```
Removed value: -9007199254740991
```
  - removedOutput schema / properties / template / properties / tasks / items / properties / offset_days / minimum
```
Removed value: --9007199254740991
```
  - removedOutput schema / properties / template / properties / tasks / items / properties / offset_days / type
```
Removed value: -"integer"
```
  - addedOutput schema / properties / template / properties / tasks / items / properties / priority_basis
```
Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "source_recorded",
+        "operational_default",
+        "operator"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
```
  - changedOutput schema / properties / template / properties / tasks / items / required
```
Previous value: -[
-  "order_index",
-  "title",
-  "description",
-  "default_status",
-  "default_priority",
-  "offset_days",
-  "duration_days"
-]New value: +[
+  "order_index",
+  "title",
+  "description",
+  "default_status",
+  "default_priority",
+  "priority_basis",
+  "offset_days",
+  "duration_days"
+]
```
1 tool updateSep 10, 2026
- Addedget_membership_offer

4 tool updatesSep 8, 2026

Changedkanbai_get_sop1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "sop": {
+      "additionalProperties": false,
+      "properties": {
+        "category": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "content": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "id": {
+          "exclusiveMinimum": 0,
+          "maximum": 9007199254740991,
+          "type": "integer"
+        },
+        "title": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "video_url": {
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "id",
+        "title",
+        "category",
+        "url",
+        "content",
+        "video_url"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "sop"
+  ],
+  "type": "object"
+}

Changedkanbai_get_template1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "template": {
+      "additionalProperties": false,
+      "properties": {
+        "description": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "id": {
+          "exclusiveMinimum": 0,
+          "maximum": 9007199254740991,
+          "type": "integer"
+        },
+        "name": {
+          "type": "string"
+        },
+        "slug": {
+          "type": "string"
+        },
+        "source_guide": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "task_count": {
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "tasks": {
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "default_priority": {
+                "type": "string"
+              },
+              "default_status": {
+                "type": "string"
+              },
+              "description": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "duration_days": {
+                "maximum": 9007199254740991,
+                "minimum": -9007199254740991,
+                "type": "integer"
+              },
+              "offset_days": {
+                "maximum": 9007199254740991,
+                "minimum": -9007199254740991,
+                "type": "integer"
+              },
+              "order_index": {
+                "maximum": 9007199254740991,
+                "minimum": -9007199254740991,
+                "type": "integer"
+              },
+              "title": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "order_index",
+              "title",
+              "description",
+              "default_status",
+              "default_priority",
+              "offset_days",
+              "duration_days"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "url": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "slug",
+        "name",
+        "description",
+        "source_guide",
+        "task_count",
+        "url",
+        "tasks"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "template"
+  ],
+  "type": "object"
+}

Changedkanbai_list_sops1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "sops": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "category": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "id": {
+            "exclusiveMinimum": 0,
+            "maximum": 9007199254740991,
+            "type": "integer"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "title",
+          "category",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "sops"
+  ],
+  "type": "object"
+}

Changedkanbai_list_templates1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "templates": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "description": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "id": {
+            "exclusiveMinimum": 0,
+            "maximum": 9007199254740991,
+            "type": "integer"
+          },
+          "name": {
+            "type": "string"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "source_guide": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "task_count": {
+            "maximum": 9007199254740991,
+            "minimum": 0,
+            "type": "integer"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "slug",
+          "name",
+          "description",
+          "source_guide",
+          "task_count",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "templates"
+  ],
+  "type": "object"
+}

4 tool updatesSep 8, 2026
- First observedkanbai_get_sop
- First observedkanbai_get_template
- First observedkanbai_list_sops
- First observedkanbai_list_templates

Related MCP Connectors

Atisbo Documentation A
io.github.brian8a1
Read-only search and page retrieval from the public Atisbo documentation corpus. No authentication.
Documentation Access Search
31
GeezerKeeper Referral Exit Routes and Deadlines A
com.geezerkeeper
Read-only senior-care exit routes, duplicate-referral deadlines, and templates; no PII or sending.
Health & Wellness
72
SHAR Public Knowledge MCP B
com.sharprod
Anonymous read-only access to source-backed public SHAR Production knowledge.
Open Data Documentation Access Search
1
Upravio public knowledge A
com.upravio
Public Upravio contract-management guides and capabilities. No private workspace access.
Legal & Compliance Documentation Access
31

Related MCP Servers

Tuyan MCP
Documentation Access Data Visualization
yrjmdqmmx
A
license
Not graded
quality
C
maintenance
Enables scientific-figure agents to retrieve versioned workflow bundles, public templates, rules, JSON Schemas, and dataset manifests through a single anonymous, read-only, stateless MCP tool.
Updated 25 days ago (2026-09-04 12:14 UTC)
Apache 2.0
@pocket-agent/mcp-server
Agent Orchestration Documentation Access
cwhited26
A
license
Not graded
quality
C
maintenance
Enables read-only access to Pocket Agent's product information, public persona templates, and app catalog. No authentication required.
Updated 2 months ago (2026-07-28 17:32 UTC)
37 npm
1
MIT
OSF CLI Go
Research & Data Open Data
edithatogo
A
license
A
quality
B
maintenance
Read-only MCP tools for authenticated Open Science Framework projects, components, files, and contributors.
Updated 2 days ago (2026-09-27 08:10 UTC)
6
1
Apache 2.0
Mediawork MCP Server
Search Entertainment & Media
screen-arts
A
license
Not graded
quality
B
maintenance
Provides read-only access to Mediawork's public directory of post-production and distribution vendors, FAQ, blog, and subscription plans through standardized MCP tools for searching and fetching records.
Updated 6 days ago (2026-09-23 08:23 UTC)
MIT

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?