Capable

Get product help

get_help

Read-only

Answer a question ABOUT CAPABLE ITSELF — how-to, setup, or troubleshooting (e.g. 'how do I connect my assistant', 'why didn't this email become a contact', 'what can each role do', 'how do I build a report'). Searches Capable's curated, hand-verified help knowledge base and returns the matching articles verbatim, each with SOURCE citations. This is NOT for the user's CRM data (use get_context / search_records for that). GROUNDING RULE — answer ONLY from the returned articles and cite the article title; do NOT add product behavior from memory. If confident is false or no returned article actually answers the question, tell the user you don't have a verified answer and point them to hello@capable.run (email is the BACKUP — remind them that asking here is much quicker). Never guess how Capable works. When an article lists related topics you may offer them as follow-ups; pass article_key to fetch one specific article.

When to use: When the user asks how Capable ITSELF works — setup, how-to, or troubleshooting ('how do I connect my assistant', 'why didn't this email become a contact', 'what can each role do'). Searches Capable's curated, verified help articles and returns them WITH source citations. NOT for the user's CRM data (use get_context / search_records). Answer only from what it returns; if it's not confident, tell the user and point them to support rather than guessing.

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

Input Schema

TableJSON 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 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

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false), so the lower bar applies. The description adds substantial behavioral context beyond annotations: the grounding rule (answer only from returned articles, cite titles, never guess), the confidence/failure path (if confident is false, direct to hello@capable.run), and the article_key fallback behavior. Only the diagnostics semantics are lightly covered.

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

Conciseness3/5

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

Content is front-loaded and well-structured, but the description is quite long with redundancy: the opening paragraph's parenthetical examples are repeated almost verbatim in the 'When to use' block, which adds bulk without new information.

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?

An output schema exists, so return format need not be explained; the description correctly focuses on what the agent must do (grounding rule, citation requirement, failure path, follow-up behavior). Given the number of sibling tools and the risk of CRM/help confusion, this is thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema documents all three parameters in detail. The description still adds meaningful semantics on top: article_key fetches a specific article and an unknown key falls back to searching it as a query, and the diagnostics parameter's read-only nature and setup-fact limits are reinforced.

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?

Opening sentence states a specific verb (Answer a question) and resource (Capable's own help knowledge base), with examples that make the scope unmistakable. It explicitly distinguishes itself from sibling tools get_context and search_records, which handle the user's CRM data.

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?

Gives an explicit when-to-use section with concrete triggers ('how Capable ITSELF works — setup, how-to, or troubleshooting'), explicit exclusions (NOT for CRM data; use get_context/search_records instead), and an example. Nothing is left to inference.

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?