Capable

Get product help

get_help

Read-only

Search verified Capable how-to/setup/troubleshooting articles verbatim with citations, or fetch article_key; offer related topics. Use get_context/search_records for CRM data. Answer ONLY from returned articles and cite titles; never guess product behavior from memory. If confident:false or no article answers, say no verified answer is available and offer hello@capable.run as backup. Call with diagnostics:true, before saying their mail or calendar isn't connected: both connect to Capable, apart from any connector this chat has. Checks saved connection/import/agent settings. Diagnostics show setup facts, not live provider health.

When to use: Questions about how Capable itself works, or checking saved connection status.

Example: How do I set up a booking link in Capable?

Input Schema

Name	Required	Description
`query`	No	The user's question about Capable itself, in their words (how-to, setup, troubleshooting); omit it and article_key to receive the help-topic catalog instead.
`article_key`	No	Fetch one specific article by its key, as returned in articles[].key or related[].key; an unknown key falls back to searching it as a query.
`diagnostics`	No	Opt in to read-only checks of your own saved email and calendar connections, imports, agent grants, and permitted workspace recording setting. Returned checks are setup facts, not live provider health; cite them only for setup status.

Output Schema

Name	Required	Description	Default
`checks`	No
`articles`	No
`guidance`	No
`confident`	No
`support_email`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 24, 2026

removedInput schema / properties / diagnostics / anyOf

Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]

addedInput schema / properties / diagnostics / type

Added value: +[
+  "boolean",
+  "string",
+  "number"
+]

Changed1 schema field changedOct 21, 2026
- addedOutput schema / properties / articles / items / properties / verified
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / diagnostics / description

Previous value: -"Opt in to read-only checks of your own saved connections, imports, agent grants, and permitted workspace recording setting. Returned checks are setup facts, not live provider health; cite them only for setup status."New value: +"Opt in to read-only checks of your own saved email and calendar connections, imports, agent grants, and permitted workspace recording setting. Returned checks are setup facts, not live provider health; cite them only for setup status."

Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
Changed8 schema fields changedOct 19, 2026
- removedOutput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
- removedOutput schema / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / articles / items / additionalProperties
```
Removed value: -false
```
- removedOutput schema / properties / articles / items / properties / ask_claude / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / articles / items / properties / ask_claude / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / articles / items / properties / related / items / additionalProperties
```
Removed value: -false
```
- removedOutput schema / properties / articles / items / properties / sources / items / additionalProperties
```
Removed value: -false
```
- removedOutput schema / properties / checks / items / additionalProperties
```
Removed value: -false
```
First observedOct 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, non-destructive), yet the description adds substantial behavior the annotations do not: verbatim search with citations required, the confident:false failure path, the hello@capable.run fallback, and the caveat that diagnostics report setup facts rather than live provider health. It also discloses the unknown-key fallback behavior. This is rich behavioral context beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Purpose and the primary alternative routing are front-loaded in the first two sentences, and the example anchors intent well. The middle section is dense, packing citation rules, failure protocol, and diagnostics caveats into long compound sentences, so it reads as somewhat cluttered rather than crisply structured.

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-required-parameter help tool with an output schema available, this covers everything an agent needs: what it searches, when to call it, how to handle low confidence, what diagnostics does and does not prove, and which sibling to prefer for CRM questions. Return shape is delegated appropriately to the output schema.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: article_key fetch vs. verbatim search, the interaction with diagnostics ('before saying their mail or calendar isn't connected'), and the scoping of diagnostics to saved settings only. It stops short of restating parameter formats, which is fine since the schema handles that.

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?

Opens with a specific verb+resource pair: 'Search verified Capable how-to/setup/troubleshooting articles verbatim with citations, or fetch article_key.' It explicitly names the sibling alternatives (get_context/search_records) as being for CRM data, so the boundary is unambiguous without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit 'When to use' clause ('Questions about Capable itself works, or checking saved connection status'), an exclusion routing rule to get_context/search_records for CRM data, and a conditional trigger for diagnostics ('before saying their mail or calendar isn't connected'). When-to-use, when-not-to-use, and alternatives are all present.

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

All Capable tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?