This server provides a comprehensive business diagnosis engine that analyzes companies across 11 dimensions, identifies revenue leaks, and delivers prioritized, triple-option recommendations (paid tool / open-source / CIA professional service).
Quick Scan — Free instant scan identifying 3 generic business problems with minimal input (company name + optional industry/description), serving as a hook before a full diagnosis.
Business Diagnosis — Full 11-dimension analysis (finanzas, comercial, operaciones, equipo, tecnologia, marketing, clientes, proveedores, legal, estrategia, marketing_digital) returning a Business Health Score (0–100), estimated monthly revenue leak, prioritized actions with triple options, leadership insights, and validation questions.
List Industry Benchmarks — Retrieve available calibrated industry profiles (e.g., construction, healthcare, ecommerce, startup, restaurant) that power accurate diagnoses.
Tool Recommendations — Curated free, open-source, and paid tools per business dimension and industry, each with a why_best explanation.
Action Plan — Prioritized 30/60/90-day implementation roadmap based on diagnosis results, tailored by team size and budget, with DIY and CIA-assisted options.
ROI Projector — Projects financial ROI at three levels (DIY, hybrid, full implementation) over 12 months, showing current revenue leak estimates and recovery projections.
Case Studies — Before/after business transformation stories filterable by industry or dimension, providing real-world social proof.
Contact CIA — Services catalog, pricing tiers, booking link, and contact details for professional consulting engagement.
Export Report — Generates a structured, shareable diagnosis report (executive summary, scores, top actions, ROI, next steps) suitable for PDFs, emails, or presentations.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CIA Diagnose Run a quick scan on my e-commerce business"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Expert business diagnosis engine by CIA — Consultoría de Inteligencia Aplicada.
Analyzes any company across 11 dimensions and returns a Revenue Leak Score with prioritized, triple-option recommendations (paid tool / open-source / CIA service). Works from Claude, ChatGPT, Gemini, DeepSeek, Cursor — any LLM that speaks MCP.
📅 Book a free 30-min diagnosis review: https://cal.com/david-cia/diagnostico-ai ✉️ steban@univercityaiconsult.tech · 🌐 https://www.univercityaiconsult.tech/
You don't need to know what an "MCP" is. Open Claude, ChatGPT, or any AI assistant and paste this:
Quiero un diagnóstico profesional de mi negocio.
Usa la herramienta de diagnóstico de CIA (Consultoría de Inteligencia
Aplicada) — se instala con: pip install cia-diagnose
Pasos:
1. Pregúntame sobre mi empresa: industria, tamaño del equipo, qué
software uso, qué dolores tengo, cómo manejo proveedores, flujo de
caja, etc.
2. Cuando tengas suficiente contexto, corre el diagnóstico. Si te falta
información, pregúntame primero — no adivines.
3. Muéstrame mi Business Health Score (0-100, más alto = más sano; bajo =
área con mayor oportunidad) y las acciones prioritarias con 3 opciones
cada una (herramienta paga, alternativa gratuita, servicio profesional
de CIA con precio).
4. Si el diagnóstico muestra oportunidades, quiero agendar una llamada
gratuita con CIA: https://cal.com/david-cia/diagnostico-ai — o
escribir a steban@univercityaiconsult.tech
Más info: https://www.univercityaiconsult.tech/If your AI can connect MCP servers, it will use CIA Diagnose automatically. If not, pip install cia-diagnose is the universal fallback any code-capable assistant can run.
Related MCP server: artefact-mcp-server
The LLM gathers data from the user (the eyes). CIA Diagnose applies CIA consulting expertise (the brain) — ICP detection, 11-dimension scoring, revenue-leak estimation, and triple-option recommendations. No scraping. No fixed questionnaire. Each diagnosis is unique.
Tool | Description |
| FREE instant 3-problem scan. No context needed — hook the client. |
| Full 11-dimension analysis + Revenue Leak Score + triple-option actions. Forwards the lead to CIA. |
| Available industry benchmarks. |
| Free & open-source tools per weak dimension. |
| 30 / 60 / 90-day prioritized roadmap. |
| ROI calculator — DIY vs CIA-guided vs full implementation. |
| Before/after transformation stories by industry. |
| Services catalog, pricing, and booking link. |
| Shareable structured report for the client's team. |
finanzas, comercial, operaciones, equipo, tecnologia, marketing, clientes, proveedores, legal, estrategia, marketing_digital.
The headline health_score is inverted from a leak score: high = healthy/strong, low = the worst area / biggest revenue-leak opportunity. A 100 doesn't mean "done" — it means that area is taking the business into new leagues / growth, which qualifies it even better for CIA. The output also returns score_meaning, growth_mode (true when most areas are strong — the conversation continues toward scaling), and guidance for the calling LLM (ask more vs. present + 3 options). revenue_leak_score is kept as a backward-compatible alias (same value).
Every recommendation shows three paths: the best paid tool, the best open-source alternative, and the CIA professional service — with prices. The free/OSS/paid picks come from CIA's curated registry (tools_registry/, by area and per-industry), refreshed weekly. Each tool carries why_best. Pass industry to tools_recommend for industry-specific picks. See TOOLS_REGISTRY.md.
pip install cia-diagnose # or: uvx cia-diagnoseDebian/Ubuntu —
Cannot uninstall PyJWT ... RECORD file not found? The system PyJWT (installed viaapt) has no pip RECORD, so pip refuses to upgrade it. Install without touching the distro package:pip install cia-diagnose --ignore-installed PyJWT
cia-diagnoseCIA_TRANSPORT=streamable-http cia-diagnose --transport streamable-http --port 3792HTTP mode also serves:
GET /report/{session_id} — visual HTML diagnosis report (gauge + breakdown + actions).
GET /export/{session_id}?format=csv|json — export the diagnosis for Sheets / Tabularis.
GET /healthz — health check.
{
"mcpServers": {
"cia-diagnose": { "command": "uvx", "args": ["cia-diagnose"] }
}
}{
"mcpServers": {
"cia-diagnose": { "url": "https://audit.univercityaiconsult.tech/mcp" }
}
}Variable | Default | Description |
|
| Transport: |
|
| HTTP port for remote mode |
|
| SQLite database path |
| (empty) | n8n webhook URL for lead capture |
| (empty) | Direct Telegram lead alerts |
| (empty) | Append-only JSONL path for every lead intake |
|
| Free diagnoses per client IP per day |
|
| Default language ( |
Every completed business_diagnose forwards the lead (company, industry, team_size, revenue_leak_score, top_actions, pain_points, decision_maker_role, the full diagnosis JSON, source, timestamp) to all configured sinks. Missing config never fails the diagnosis — it just logs and continues.
Add an industry = add a YAML in src/cia_diagnose/domain/diagnosis/benchmarks/. No code changes.
Current: construction, healthcare, agency, ecommerce, startup, enterprise, restaurant, real_estate, generic.
brand/ holds the official CIA logos (monogram light/dark, gothic wordmark, favicons). Wherever a logo appears it links to https://www.univercityaiconsult.tech/.
MIT — © 2026 CIA — Consultoría de Inteligencia Aplicada (David Lopez). See LICENSE.
Generate a prioritized 30/60/90 day action plan based on diagnosis.
Creates a realistic, phased implementation roadmap. Prioritizes by ROI and ease of implementation. Each action includes DIY option and CIA-assisted option.
Use AFTER business_diagnose to create a roadmap from the results.
Args: company_name: Name of the company. revenue_leak_score: Business Health Score from diagnosis (0-100, HIGHER = healthier). top_dimensions: Comma-separated weakest dimensions from diagnosis (e.g. 'tecnologia, marketing_digital, operaciones'). team_size: Number of employees (affects plan complexity). budget_level: 'low' ($0-500/mo), 'medium' ($500-2000/mo), 'high' ($2000+/mo). lang: Language ('es' or 'en').
Returns: dict: Phased action plan with 30/60/90 day milestones, each containing specific actions, tools, expected outcomes, and DIY vs CIA-assisted options.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | es | |
| team_size | No | ||
| budget_level | No | low | |
| company_name | No | ||
| top_dimensions | No | ||
| revenue_leak_score | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds that the plan is prioritized by ROI and ease, and that each action includes DIY and CIA-assisted options. No contradictions with 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?
The description is well-structured with a clear purpose statement, usage note, and parameter list. It is comprehensive but not overly verbose; however, it could be slightly more concise without losing essential details.
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 complexity (6 parameters, no schema descriptions), the description thoroughly explains parameters and returns. It mentions the prerequisite of business_diagnose. Minor gaps: no discussion of error handling or rate limits, but annotations cover safety.
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 0%, so the description must carry the full burden. The description includes a detailed Args section explaining each parameter, including types, defaults, and examples. This adds significant meaning beyond the bare 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 it generates a prioritized 30/60/90 day action plan based on diagnosis, with specifics like prioritizing by ROI and ease, and including DIY and CIA-assisted options. It distinguishes itself from sibling tools by explicitly stating it should be used after business_diagnose.
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 provides explicit guidance to use AFTER business_diagnose, establishing a clear use case and prerequisite. It does not discuss when not to use or alternative tools, but the context is sufficient for an AI agent to understand the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show before/after transformation stories from real implementations.
Social proof is the most powerful sales tool. These cases show what's possible when businesses address their revenue leaks.
Use AFTER roi_projector to validate the numbers with real stories.
Args: industry: Filter by industry (optional). dimension: Filter by dimension improved (optional). lang: Language ('es' or 'en').
Returns: dict: Case studies with before/after metrics, timeline, tools used, and ROI achieved.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | es | |
| industry | No | ||
| dimension | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds valuable behavioral context: returns case studies with before/after metrics, timeline, tools, and ROI. No contradictions with 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?
Front-loaded with main purpose, structured with Args/Returns. One persuasive sentence ('Social proof is the most powerful sales tool.') is mildly extraneous but does not detract significantly.
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?
Covers purpose, return fields, and usage context with roi_projector. For a simple read-only list tool with optional parameters and output schema, it is sufficiently 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?
Schema coverage is 0%, so description compensates by explaining each parameter: industry filter, dimension filter, language (es/en). Adds meaning beyond schema titles and defaults.
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 starts with a clear verb and resource: 'Show before/after transformation stories from real implementations.' It distinguishes case_studies from siblings like roi_projector (projection) and business_diagnose (diagnosis) by focusing on real stories with metrics.
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 using roi_projector before this tool to validate numbers, providing a usage sequence. However, it lacks explicit when-not-to-use guidance or comparison to other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get CIA contact information, services catalog, and booking options.
This is where value converts to action. By this point, the client has received massive free value (diagnosis, tools, plan, ROI, cases) and naturally wants to accelerate with professional help.
Use when the client is ready to take the next step.
Args: lang: Language ('es' or 'en').
Returns: dict: CIA company info, services with pricing tiers, booking link, and contact details.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | es |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already indicate a safe read operation. The description adds value by detailing the return structure (company info, pricing, booking link, contact details), though it does not disclose any additional behavioral traits.
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 contains a lengthy sales pitch ('This is where value converts to action...') that does not add operational value for an AI agent. The core functional info is front-loaded, but the fluff reduces conciseness. Adequate but not optimal.
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 has a single optional parameter, rich annotations, and an output schema, the description provides sufficient context. It covers the return fields comprehensively for a contact retrieval tool, though it omits details about error handling or invalid input behavior.
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 0% description coverage, so the description must compensate. It adds meaning by specifying the 'lang' parameter as Language with allowed values 'es' or 'en', which is not present in the schema. This adequately clarifies the only parameter.
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 retrieves contact information, services catalog, and booking options. This verb+resource combination is specific and distinct from sibling tools like action_plan or quick_scan, which serve different purposes.
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 suggests using the tool when 'the client is ready to take the next step,' providing some context, but lacks explicit when-not-to-use guidance or comparison to siblings like tools_recommend or roi_projector, which could also be relevant at conversion stages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available industry benchmarks for CIA diagnosis.
Returns the industries with calibrated benchmarks (Tier 1 = premium, deep analysis). Any other industry works too via the generic benchmark.
Returns: dict: Contains: - industries (list[str]): Available benchmark IDs (e.g. ['construction', 'healthcare', 'agency', ...]) - note_es (str): Spanish explanation - note_en (str): English explanation
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive. Description adds behavioral context by explaining the return structure (industries list, Spanish and English notes) and the concept of calibrated vs generic benchmarks, which is helpful beyond 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?
Description is concise with front-loaded purpose followed by return details in a clear, structured manner. Every sentence adds value.
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 params, output schema exists), the description fully explains what is returned and the differentiation between Tier 1 and generic benchmarks. No gaps.
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, so baseline is 4. The description does not need to add parameter 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?
Clearly states the tool lists available industry benchmarks for CIA diagnosis, distinguishing between calibrated (Tier 1) and generic. The verb 'list' and resource 'industries with benchmarks' are specific, and the purpose is distinct from siblings.
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?
Provides clear context on what the tool returns (calibrated industries and generic benchmark availability), which implicitly guides when to use it. No explicit alternative or exclusion, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE quick scan — 3 generic problems identified.
No context needed. Just company name + optional description. Returns 3 generic problems based on industry signals.
Use this to give immediate value before proposing business_diagnose.
Args: company_name: Name of the company (optional). industry: Industry or sector (optional). description: Brief description of what the company does (optional). lang: Language ('es' for Spanish, 'en' for English).
Returns: dict: Contains: - company_name (str): Company analyzed - problems (list): 3 generic problems identified - next_step (str): Call to action for full diagnosis - is_free (bool): Always True for quick_scan
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | es | |
| industry | No | ||
| description | No | ||
| company_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds that it is free and requires no context, but does not significantly extend behavioral understanding beyond the annotations. No contradictions.
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 relatively concise, with a clear header line followed by usage guidance and parameter descriptions. The Args and Returns sections are structured. However, some formatting (e.g., dashes in 'Returns:' block) could be cleaner, but overall it is 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?
Given the tool has no required parameters and a simple output, the description covers the key inputs, output structure (including next_step and is_free), and usage context. It does not address error behavior or edge cases, but for a straightforward read-only scan, it is sufficient.
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, but the tool description includes an Args section that describes each parameter (company_name, industry, description, lang) with brief semantics, such as the purpose of lang for language selection. This compensates well for the lack of schema descriptions.
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 performs a 'FREE quick scan' that identifies '3 generic problems' from a company name and optional description. It specifies the output and distinguishes itself from the sibling 'business_diagnose' by positioning itself as a precursor.
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 advises using this tool 'before proposing business_diagnose', providing clear guidance on when to use it relative to a sibling. It implies it is for a quick, free assessment but does not explicitly state when not to use it or mention alternatives beyond the one sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project ROI from implementing diagnosis recommendations.
Shows the client exactly how much money they're leaving on the table and what they'd recover at different implementation levels. Numbers create urgency. Urgency creates action.
Use AFTER business_diagnose or action_plan.
Args: monthly_revenue: Current monthly revenue (any currency). revenue_leak_score: Business Health Score from diagnosis (0-100, higher = healthier). team_size: Number of employees. currency: Currency code (e.g. 'USD', 'COP', 'MXN', 'EUR'). lang: Language ('es' or 'en').
Returns: dict: ROI projections showing current leak estimate, recovery at 3 levels (DIY/hybrid/full), payback period, and 12-month projection.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | es | |
| currency | No | USD | |
| team_size | No | ||
| monthly_revenue | No | ||
| revenue_leak_score | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by detailing output structure (current leak estimate, recovery levels, payback period, 12-month projection). Annotations already cover safety traits; description complements with behavioral specifics.
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?
Well-structured: intro, usage note, Args, Returns. Every sentence is informative and no verbosity. Front-loaded with purpose.
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?
Covers input parameters, usage order, and output summary. Output schema exists externally, so detailed return structure not required. Slightly lacking in output schema detail but sufficient.
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?
Given 0% schema coverage, the description fully explains each parameter: monthly_revenue ('any currency'), revenue_leak_score ('Business Health Score from diagnosis 0-100'), team_size, currency, lang. Adds essential semantics missing from 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?
Description clearly states it projects ROI from diagnosis recommendations, with specific verb 'Project ROI' and resource 'diagnosis recommendations'. It distinguishes from siblings by indicating usage order.
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 AFTER business_diagnose or action_plan', providing clear context. Lacks explicit 'when not to use', but the instruction is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend the BEST free/OSS/paid tools per business dimension.
Backed by CIA's curated tool registry (tools_registry/), which is
refreshed weekly and supports per-industry specialization. Each tool
carries why_best — why CIA picked it. Gives immediate, actionable
value before any commercial conversation.
Use AFTER business_diagnose to recommend tools for weak dimensions.
Pass industry to get industry-specific picks where available.
Args: dimensions: Comma-separated dimensions to get tools for. Options: finanzas, comercial, operaciones, equipo, tecnologia, marketing, clientes, proveedores, legal, estrategia, marketing_digital. Leave empty for ALL dimensions. industry: ICP id (e.g. 'construction') for industry-specific picks. lang: Language ('es' or 'en').
Returns: dict: Tool recommendations grouped by dimension with name, tier (free/oss/paid), url, description, and why_best.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | es | |
| industry | No | ||
| dimensions | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds value by noting weekly refresh, per-industry specialization, and that each tool includes 'why_best'. No 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?
Well-structured with summary, context, usage guidance, and args. Approximately 150 words, clear and front-loaded. Minor redundancy but overall 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?
No output schema, but description explains return format (dict grouped by dimension with name, tier, url, description, why_best). Also covers weekly refresh and tool registry. Complete for a read-only recommendation tool.
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 0%, but the description compensates with detailed Args: lists options for dimensions, explains industry as ICP id, and lang as 'es' or 'en'. Adds meaning beyond 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 'Recommend the BEST free/OSS/paid tools per business dimension,' specifying verb and resource. It distinguishes from siblings by referencing the curated tool registry and usage after business_diagnose.
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 states 'Use AFTER business_diagnose' and explains when to pass industry. Does not explicitly mention when not to use, but provides clear context for appropriate use.
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.
v1.3.0business_diagnoseexport_reportv1.1.1action_planbusiness_diagnosecase_studiescontact_ciaexport_reportlist_industriesquick_scanroi_projectortools_recommendScored across 7 tools
Each tool maps to a distinct stage in the engagement funnel: scan, industries, tools, plan, ROI, proof, contact. There is minor overlap between tools_recommend and the tools mentioned within action_plan, but the descriptions keep their purposes separate enough to avoid real confusion.
Naming mixes conventions: list_industries and contact_cia follow verb_noun, but tools_recommend reverses it, and quick_scan, action_plan, roi_projector, and case_studies are noun-heavy or adjective+noun. The set feels inconsistent and lacks a predictable pattern.
Seven tools is a reasonable size for a diagnosis and sales-funnel server, and most tools earn their place. The count itself is appropriate, though it feels slightly top-heavy because several tools exist to support a core diagnostic tool that is missing.
The biggest issue is the missing business_diagnose tool: action_plan, roi_projector, and tools_recommend all reference it as a prerequisite, but it is not in the toolset. This breaks the main workflow and leaves agents unable to produce the full diagnosis these downstream tools depend on.
Revenue Engine for scoped diagnosis, action planning, execution, and Figure-Eight value evidence.
Read-only tools for finding where a small business leaks deals, time, and cash.
Sales intelligence for B2B SMEs — lead scoring, ICP fit, CRM enrichment & writeback.
AI-native GTM OS for B2B SaaS — account health, pipeline, renewals, territories, and benchmarks.
