Built with Jon — Hidden Profit Tools
Server Details
Read-only tools for finding where a small business leaks deals, time, and cash.
- 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/5 across 10 of 10 tools scored. Lowest: 3.2/5.
Each tool targets a distinct purpose: calculators, articles, frameworks, use cases, scorecard, and review info. There is no overlap; even related tools like 'search_use_cases' and 'get_use_case' are clearly complementary.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., calculate_leak, list_leak_calculators, run_scorecard), making them predictable and easy to distinguish.
With 10 tools, the server covers a broad but focused domain (small-business workflows, automation, and profit leaks) without being overly numerous or sparse. Each tool serves a clear function.
The tool surface is complete for its domain: it includes search and retrieval for articles and use cases, interactive calculators, a scorecard, frameworks, and a paid review option. No obvious missing operations.
Available Tools
11 toolscalculate_leakAInspect
Put a monthly/annual dollar figure on one operational leak using Built with Jon's Leak Calculator math (identical to the website's). Call when a user wants to know what missed calls, slow follow-up, no-shows, unbilled change orders, or aging invoices are costing them. Missing inputs fall back to illustrative defaults and are flagged.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | No | Numbers keyed by the field names from list_leak_calculators; omit any you don't know | |
| calculator_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the fallback behavior for missing inputs ('fall back to illustrative defaults and are flagged'), which is a key behavioral trait. With no annotations provided, the description sufficiently conveys tool behavior as a read-only calculator, though it does not explicitly state nondestructive nature.
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 three sentences, each adding value: first states core function, second clarifies usage, third flags fallback behavior. No redundant or irrelevant 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 calculator tool with two parameters and no output schema, the description adequately covers purpose, usage, and key behavior (defaults). However, it does not describe the return format (e.g., JSON structure), which would be helpful for the agent.
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 description adds some context by mentioning fallback defaults and example leaks, but the input schema already describes calculator_id via an enum and inputs as keyed numbers. The description does not explain the structure of inputs further, and with 50% schema coverage, it compensates only marginally.
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 calculates a monthly/annual dollar figure for operational leaks, using a specific math model. It lists example leaks (missed calls, slow follow-up, etc.) and contrasts with sibling tools like list_leak_calculators which only list calculators.
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 says 'Call when a user wants to know what ... are costing them,' providing clear usage context. It does not specify when not to use it or mention alternatives, but the sibling tool list_leak_calculators is implied for retrieving calculator IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_articleAInspect
Get one article by slug (from search_articles), including its canonical URL and full markdown text when available.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Article slug, e.g. 'missed-call-math-home-services' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that markdown text is included 'when available', indicating variability, but does not mention error behavior, rate limits, or what happens if slug is not found.
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 efficiently conveys action, source, and contents. Front-loaded with key information, no extraneous 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?
For a simple retrieval tool with one parameter and no output schema, the description covers return contents and source. Lacks detail on return format or error handling, but adequate given tool simplicity and sibling 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?
Schema coverage is 100% and already describes the slug parameter with an example. The description adds no additional semantic value beyond stating the tool is 'by slug'.
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 retrieves one article by slug, mentions specific return contents (canonical URL, full markdown text), and references the sibling tool search_articles as the source of the slug, distinguishing it from similar tools.
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 slug should come from search_articles, which provides usage context, but does not explicitly state when to use this tool vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_frameworksBInspect
Get Built with Jon's decision frameworks: the Five Dispositions (the five-question treatment every workflow step gets before anyone automates anything) and the 5-phase implementation process. Call when discussing how to decide what to automate.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It fails to detail behavior like default behavior when 'section' is omitted, or what the returned data looks like. The description only lists the framework names without explaining return format or side effects.
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 short and front-loaded, with a single sentence plus a usage directive. No extraneous information, but it could be better structured (e.g., listing the two frameworks).
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 low complexity (one optional parameter, no output schema), the description is incomplete. It lacks parameter explanation and does not specify what each section returns, leaving gaps for the agent.
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, yet the description does not mention the 'section' parameter at all. It does not explain the meaning or expected output of each enum value ('dispositions', 'process', 'all'), leaving the agent uninformed.
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 that the tool retrieves Jon's decision frameworks, specifically naming the Five Dispositions and the 5-phase implementation process. This distinguishes it from sibling tools like 'get_use_case' or 'run_scorecard'.
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 says 'Call when discussing how to decide what to automate', providing a clear usage context. However, it does not mention when not to use this tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_use_caseAInspect
Get one use case from the library in full: the pain, the workflow as it actually runs, per-step verdicts (eliminate / simplify / automate / optimize / report) with rationale, where AI genuinely fits, and the after state. Ids look like 'A1' or 'S3'.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Use case id, e.g. 'A1' |
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 burden. It details the content returned (pain, workflow, verdicts) but does not explicitly state it is a read-only operation or mention side effects, authentication, or rate limits. The verb 'Get' implies reading, but additional behavioral context is missing.
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 sentences: first clearly states action and response content, second specifies ID format. No redundant or missing 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 single-resource retrieval with one parameter, the description covers what the tool returns in sufficient detail. It does not mention error cases or prerequisites, but overall it is adequately complete for the tool's simplicity.
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 describes 'id' with 100% coverage, but the description adds extra context on ID format ('Ids look like 'A1' or 'S3'') beyond the schema's example, clarifying valid values.
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 uses specific verbs ('Get') and clearly identifies the resource ('one use case from the library in full'), enumerating the included fields (pain, workflow, verdicts, etc.). It distinguishes from sibling 'search_use_cases' which implies a different purpose.
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 usage when full details of a specific use case are needed, and the ID format is provided. However, it does not explicitly state when not to use or mention alternatives like 'search_use_cases' for finding use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_leak_calculatorsAInspect
List the 10 leak calculators (missed calls, slow bids, unbilled change orders, unanswered inquiries, engagement-letter delay, cold DMs, slow quotes, no-shows, first-reply speed, invoice aging) with their input fields and defaults. Use before calculate_leak.
| 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 must convey behavior. The verb 'list' inherently implies a read-only, non-destructive operation, which is clearly conveyed. Additionally, the description outlines exactly what is returned (10 specific calculators with fields and defaults), adding transparency beyond the schema.
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 sentences with no wasted words. The first sentence states the action and enumerates the items, the second gives a usage hint. Fully front-loaded and efficient.
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 list tool with no parameters, the description fully covers what the tool does and what it returns. It also provides context by linking to 'calculate_leak,' making the usage workflow clear.
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 zero parameters and 100% coverage, so the description is not required to elaborate on parameters. The baseline for zero params is 4, and the description adds no unnecessary information.
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 action 'list' and specifies it returns the 10 named leak calculators with their input fields and defaults. It distinguishes from the sibling 'calculate_leak' by advising use before that tool, making purpose unambiguous.
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 before calculate_leak,' providing a clear sequence hint for when to invoke this tool. While it doesn't list when not to use, the direct guidance is sufficient for this context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_use_case_categoriesAInspect
List the 15 categories of the Built with Jon Use Case Library (96 worked small-business AI/automation examples), grouped by business function, industry, and personal, with counts and key stats. Call this first to orient before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes a read-only listing operation without side effects, but does not explicitly state it is non-destructive or safe. Adequate but could be more explicit.
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 concise sentences. First covers purpose and output; second gives usage guidance. No wasted 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?
Given the tool's simplicity (no parameters, no output schema), the description sufficiently explains what it returns (15 categories, grouping, counts, stats) and how to use it first for orientation.
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?
No parameters exist in the input schema, so schema coverage is 100%. Description adds no parameter information, but none is needed. Baseline 3 applies.
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 lists 15 categories of the Use Case Library, grouped by business function, industry, and personal, with counts and stats. Distinguishes itself from siblings by advising to call this first before searching.
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 advises 'Call this first to orient before searching,' providing clear context for when to use. Does not include explicit when-not-to-use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_scorecardAInspect
Run Built with Jon's 3-minute AI Workflow Scorecard: ask the user these questions conversationally, then call this with their answers to get a scored verdict on where their business is leaking deals, time, and cash — plus the first fix worth making. Same deterministic scoring as builtwithjon.com/scorecard/. No email or signup involved.
| Name | Required | Description | Default |
|---|---|---|---|
| q2 | Yes | A new lead comes in. How fast does someone respond? | |
| q3 | Yes | A lead doesn't buy right away. Then what? | |
| q4 | No | Roughly how many new leads or inquiries come in a month? (optional — flavors the reading, does not affect the score) | |
| q5 | No | How many hours a week do you spend on admin, chasing status, and re-typing the same information? (optional — flavors the reading, does not affect the score) | |
| q6 | Yes | How much of your work lives across separate tools you copy between by hand? | |
| q7 | Yes | How often does work get redone because of a miss, a gap, or bad information? | |
| q8 | Yes | After work is done, how fast do you invoice and get paid? | |
| q9 | No | Last one, and you can skip it. Roughly, what's monthly revenue? (optional — flavors the reading, does not affect the score) | |
| segment | Yes | What kind of business is this? gc = General contracting; re = Real estate; hs = Home services & trades; pm = Property management; ps = Professional services; hw = Health & wellness; cc = Coaching or creator; general = Something else / general business |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes deterministic scoring, the result includes a 'scored verdict' and 'first fix,' and explicitly states no email or signup needed. Since no annotations are provided, this gives adequate behavioral insight without contradiction.
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 tool's purpose in the first sentence. It is a single paragraph, efficient, and every sentence adds value (purpose, usage, benefit). Could be slightly shorter but 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?
Although there is no output schema, the description explains the return value: a 'scored verdict' and 'first fix.' For the complexity (9 parameters, deterministic), this provides sufficient completeness for an agent to understand 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 coverage is 100% with clear descriptions per parameter. The description does not add new parameter-level context beyond stating to ask conversationally, so a baseline score of 3 is appropriate.
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 explicitly states it runs a scorecard, asks questions, and returns a verdict. It clearly differentiates from sibling tools like calculators and articles (which are informational) by focusing on scoring a business workflow.
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 instructs to 'ask the user these questions conversationally, then call this with their answers,' providing clear guidance on when to use the tool. It lacks explicit when-not-to-use statements but is sufficiently clear for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_articlesAInspect
Search Jonathan Malkin's ~50 articles on small-business workflow leaks, Claude Code infrastructure (the Jules system), AI agents, and AI operations. Filter by keyword and/or tag; returns titles, descriptions, and slugs for get_article.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Exact tag match, case-insensitive | |
| limit | No | Max results, 1-20 (default 10) | |
| query | No | Keyword matched against title, description, tags, and body |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It describes the output (titles, descriptions, slugs) and search scope, but does not disclose read-only behavior or any potential side effects.
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?
Single sentence that is front-loaded with specific scope and purpose. Every word adds value; no fluff.
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 output schema, the description adequately explains what the tool returns and how to use it. It covers the search scope and parameter usage sufficiently.
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 100%, so baseline is 3. The description confirms filtering by keyword and tag but adds no additional meaning beyond the 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 clearly states the tool searches Jonathan Malkin's articles on specific topics and returns titles, descriptions, and slugs. It is distinguished from sibling tool get_article by specifying the output format.
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 explains filtering by keyword and/or tag, but does not explicitly mention when to avoid using it or provide alternatives. It indirectly implies get_article for full content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_use_casesAInspect
Search the 96-entry Use Case Library of small-business AI and automation workflows. Call this when a user describes a recurring business pain (missed leads, invoice chasing, status meetings, no-shows...) to find worked examples with per-step automation verdicts. Filter by keyword, category, frequency, automation level, or disposition.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Keyword matched against name, subject, pain line, workflow steps, and AI-fit text | |
| frequency | No | Substring match on frequency, e.g. 'daily', 'weekly', 'monthly', 'per hire' | |
| automation | No | ||
| category_id | No | Category id from list_use_case_categories | |
| disposition | No | Only use cases where some step gets this verdict |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions searching across specific fields (name, subject, pain line, etc.) and returns 'worked examples with per-step automation verdicts'. However, it does not disclose pagination, ordering, or any limitations, leaving some behavioral aspects ambiguous.
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 sentences: first states purpose, second gives usage context and available filters. No unnecessary words, front-loaded with essential 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?
The description provides sufficient context for a search tool: it explains the resource (96-entry library), when to call (recurring pain), and filter options. While it does not describe return structure in detail (no output schema), the hint 'per-step automation verdicts' gives enough expectation.
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 80%, with each parameter having a basic description. The description adds 'Filter by keyword, category, frequency, automation level, or disposition' but does not provide new meaning beyond the schema. Baseline of 3 applies.
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 searches a 96-entry Use Case Library of small-business AI workflows. It uses a specific verb ('Search') and resource ('Use Case Library'), and distinguishes from siblings like 'get_use_case' (single item) and 'list_use_case_categories' (categories).
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 'Call this when a user describes a recurring business pain...' providing clear context for use. It implies when not to use (e.g., if user wants a specific use case) but does not directly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_hereAInspect
START HERE if you are new to Built with Jon. Explains every tool, why to use it, what it returns, how the tools work together, and the best first prompt for finding a leak in deals, time, or cash.
| 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 burden. It explains what the tool does (explains tools, returns explanations) but does not detail specifics like output format (e.g., text, list) or any side effects. It adds useful behavioral context but lacks full transparency.
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 a single, front-loaded sentence that wastes no words. Every part ('START HERE', 'Explains every tool', etc.) serves a purpose, earning 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 the tool's simplicity (introductory, no params, no output schema), the description covers its core function well. It explains what it does and for whom. A minor improvement would be to specify the output format (e.g., text response, list), but it remains mostly 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?
The input schema has zero parameters and 100% coverage, so the baseline is 4. The description adds no param-specific info, but none is needed. It adequately describes the tool's action without referencing parameters.
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 as an entry point for new users, explaining all tools and providing a first prompt. It uses specific verbs ('explains', 'gives') and distinguishes itself from sibling tools by being the only introductory guide.
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 instructs to 'START HERE if you are new', providing clear context for when to use this tool versus alternatives. It implies not to use it if already familiar, effectively guiding the agent.
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!