The HUMMBL MCP Server provides programmatic access to the Base120 framework of 120 validated mental models organized across 6 transformation types (P-Perspective, IN-Inversion, CO-Composition, DE-Decomposition, RE-Recursion, SY-Meta-Systems) for cognitive problem-solving and decision-making.
Core Capabilities:
Retrieve mental models - Get detailed information about specific models by code (e.g., P1, IN3)
List all models - View all 120 models with optional filtering by transformation type
Search models - Find models by keyword across names, descriptions, and codes
AI-powered recommendations - Get tailored model suggestions based on natural language problem descriptions
Explore transformations - Retrieve detailed information about transformation types and their associated models
Search problem patterns - Discover predefined problem patterns with recommended approaches
Access methodology - Retrieve the Self-Dialectical AI Systems methodology and audit model references
URI-based access - Direct access to models, transformations, and documentation via hummbl:// URIs
Click on "Install 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., "@HUMMBL MCP Server recommend models for improving team decision-making under uncertainty"
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.
Give Claude access to 120 validated mental models — for sharper analysis, clearer decision-making, and systematic problem-solving across six cognitive transformations.
Repository health contract: docs/REPO_HEALTH.md
HUMMBL Base120 is a comprehensive cognitive framework consisting of 120 validated mental models organized across 6 transformations:
P (Perspective): Change viewpoint to see problems differently
IN (Inversion): Flip problem to find solution by avoiding failure
CO (Composition): Combine elements to create emergent properties
DE (Decomposition): Break down complexity into manageable components
RE (Recursion): Apply patterns at multiple scales and iterations
SY (Meta-Systems): Understand rules, patterns, and systems governing systems
Learn more at hummbl.io.
Related MCP server: think-mcp
npm is the authoritative public registry for v1.2.0. The GitHub Packages mirror is pending — see PACKAGE_PUBLICATION_RECEIPT.md for details.
npm install -g @hummbl/mcp-servernpx @hummbl/mcp-serverThe same build is mirrored to GitHub Packages as @hummbl-dev/mcp-server. GitHub Packages requires a GitHub personal access token with read:packages scope even for public installs — create one at https://github.com/settings/tokens.
Note: The v1.2.0 GitHub Packages mirror is pending. Use npm for the current v1.2.0 release. See PACKAGE_PUBLICATION_RECEIPT.md for details.
Add to your project's .npmrc:
@hummbl-dev:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=YOUR_GITHUB_PATThen install:
npm install @hummbl-dev/mcp-serverAdd to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"hummbl": {
"command": "npx",
"args": ["-y", "@hummbl/mcp-server"]
}
}
}get_methodologyRetrieve the canonical Self-Dialectical AI Systems methodology, including all stages and HUMMBL Base120 references.
Example:
{}audit_model_referencesAudit a list of HUMMBL model references for validity, duplication, and transformation alignment.
Example:
{
"items": [
{ "code": "IN11", "expectedTransformation": "IN" },
{ "code": "CO4" }
]
}After configuration, restart Claude Desktop. The HUMMBL tools will appear in the attachment menu.
get_modelRetrieve detailed information about a specific mental model.
Example:
{
"code": "P1"
}list_all_modelsList all 120 mental models, optionally filtered by transformation type.
Example:
{
"transformation_filter": "P"
}search_modelsSearch models by keyword across names, descriptions, and examples.
Example:
{
"query": "decision"
}recommend_modelsGet AI-recommended models based on problem description.
Example:
{
"problem_description": "Our startup is growing rapidly but systems are breaking down. We need to scale operations without losing quality."
}get_transformationRetrieve information about a specific transformation type and all its models.
Example:
{
"type": "IN"
}search_problem_patternsFind pre-defined problem patterns with recommended approaches.
Example:
{
"query": "innovation"
}export_modelsExport a curated subset of Base120 models as Markdown or JSON — useful for docs, decks, or feeding models into another LLM's context. Pass codes for a specific list, transformation for a whole group, or neither for all 120.
Example:
{
"format": "markdown",
"codes": ["P1", "IN3", "CO5", "DE1"]
}Scenario: You want to understand "First Principles Thinking" before applying it to a problem.
// Request
{
"tool": "get_model",
"arguments": {
"code": "P1"
}
}
// Response
{
"model": {
"code": "P1",
"name": "First Principles Framing",
"definition": "Reduce complex problems to foundational truths that cannot be further simplified",
"priority": 1,
"transformation": "P"
}
}When to use: Starting a new problem analysis by identifying core assumptions and fundamentals.
Scenario: You know you need to look at a problem from different perspectives but want to see all available perspective models.
// Request
{
"tool": "list_all_models",
"arguments": {
"transformation_filter": "P"
}
}
// Response
{
"total": 20,
"models": [
{
"code": "P1",
"name": "First Principles Framing",
"definition": "Reduce complex problems to foundational truths...",
"priority": 1,
"transformation": "P"
},
{
"code": "P2",
"name": "Stakeholder Mapping",
"definition": "Identify all parties with interest, influence...",
"priority": 1,
"transformation": "P"
}
// ... 18 more models
]
}When to use: Exploring all models within a specific transformation category to find the right approach.
Scenario: You're making a strategic decision and want to find all mental models related to decision-making.
// Request
{
"tool": "search_models",
"arguments": {
"query": "decision"
}
}
// Response
{
"query": "decision",
"resultCount": 8,
"results": [
{
"code": "P2",
"name": "Stakeholder Mapping",
"definition": "Identify all parties with interest, influence, or impact in a system or decision",
"priority": 1,
"transformation": "P"
},
{
"code": "SY3",
"name": "Decision Trees & Game Theory",
"definition": "Model sequential choices and strategic interactions with payoff structures",
"priority": 1,
"transformation": "SY"
}
// ... 6 more results
]
}When to use: Finding relevant models across all transformations for a specific concept or challenge.
Scenario: Your startup is scaling rapidly but systems are breaking down—you need guidance on which mental models to apply.
// Request
{
"tool": "recommend_models",
"arguments": {
"problem": "Our startup is growing rapidly but systems are breaking down. We need to scale operations without losing quality."
}
}
// Response
{
"problem": "Our startup is growing rapidly but systems are breaking down...",
"recommendationCount": 2,
"recommendations": [
{
"pattern": "Complex system to understand",
"transformations": [
{
"key": "DE",
"name": "Decomposition",
"description": "Break down complexity into manageable components"
}
],
"topModels": [
{
"code": "DE1",
"name": "Modular Decomposition",
"definition": "Break systems into independent, interchangeable components...",
"priority": 1
},
{
"code": "DE2",
"name": "Layered Architecture",
"definition": "Organize systems into hierarchical strata with clear interfaces",
"priority": 1
}
]
},
{
"pattern": "Strategic or coordination challenge",
"transformations": [
{
"key": "SY",
"name": "Meta-Systems",
"description": "Understand rules, patterns, and systems governing systems"
}
],
"topModels": [
{
"code": "SY1",
"name": "Feedback Loops & Causality",
"definition": "Trace how outputs loop back as inputs creating reinforcing or balancing dynamics",
"priority": 1
}
]
}
]
}When to use: You have a complex, multi-faceted problem and need AI-driven recommendations on where to start.
Scenario: You've heard about "inversion thinking" and want to understand all the models in that category.
// Request
{
"tool": "get_transformation",
"arguments": {
"key": "IN"
}
}
// Response
{
"key": "IN",
"name": "Inversion",
"description": "Reverse assumptions. Examine opposites, edges, negations.",
"modelCount": 20,
"models": [
{
"code": "IN1",
"name": "Subtractive Thinking",
"definition": "Improve systems by removing elements rather than adding complexity",
"priority": 1
},
{
"code": "IN2",
"name": "Premortem Analysis",
"definition": "Assume failure has occurred and work backward to identify causes",
"priority": 1
}
// ... 18 more models
]
}When to use: Deep-diving into a transformation to understand its philosophy and available models.
Scenario: Your team struggles with innovation—everything feels incremental. You want to find pre-defined patterns that match this challenge.
// Request
{
"tool": "search_problem_patterns",
"arguments": {
"query": "innovation"
}
}
// Response
{
"query": "innovation",
"patternCount": 1,
"patterns": [
{
"pattern": "Stuck in conventional thinking",
"transformations": ["IN"],
"topModels": ["IN1", "IN2", "IN3"]
}
]
}When to use: You recognize a common problem type and want to quickly jump to the recommended mental models and approaches.
HUMMBL now includes guided multi-turn workflows that walk you through systematic problem-solving using mental models. Perfect for complex problems that benefit from structured analysis.
Use when: Investigating failures, incidents, or recurring problems Duration: 20-30 minutes Sequence: P → IN → DE → SY
Systematically find root causes, not just symptoms.
Use when: Creating strategies, planning initiatives, entering markets Duration: 30-45 minutes Sequence: P → CO → SY → RE
Design comprehensive strategies with creative combinations and systemic thinking.
Use when: High-stakes decisions with uncertainty Duration: 15-25 minutes Sequence: P → IN → SY → RE
Make quality decisions through clear framing, stress-testing, and systematic evaluation.
list_workflowsList all available guided workflows.
{
"tool": "list_workflows"
}start_workflowBegin a guided workflow for your problem.
{
"tool": "start_workflow",
"arguments": {
"workflow_name": "root_cause_analysis",
"problem_description": "Our production API started failing intermittently after yesterday's deployment"
}
}continue_workflowProceed to the next step after completing current step.
{
"tool": "continue_workflow",
"arguments": {
"workflow_name": "root_cause_analysis",
"current_step": 1,
"step_insights": "Identified 3 affected stakeholders: customers experiencing timeouts, internal services with cascading failures, and ops team receiving alerts. Core assumption: the deployment changed something fundamental in request handling."
}
}find_workflow_for_problemDiscover which workflow best fits your problem.
{
"tool": "find_workflow_for_problem",
"arguments": {
"problem_keywords": "system failure production"
}
}Step 1 (Perspective):
{
"currentStep": 1,
"totalSteps": 4,
"transformation": "P",
"guidance": "Frame the problem clearly from multiple perspectives",
"suggestedModels": ["P1", "P2", "P15"],
"questions": [
"What are the foundational facts we know for certain?",
"Who is affected and how?",
"What assumptions are we making?"
]
}After completing Step 1, continue:
{
"tool": "continue_workflow",
"arguments": {
"workflow_name": "root_cause_analysis",
"current_step": 1,
"step_insights": "Your insights here..."
}
}Step 2 (Inversion): Test boundaries, work backward from failure Step 3 (Decomposition): Isolate the failing component Step 4 (Meta-Systems): Design systemic fixes and prevention
MCP prompts are user-invocable templates. In Claude Desktop they appear in the "Attach from MCP" menu and can be selected to kick off a conversation. All prompts take a free-text problem argument; apply_model also takes a model_code.
Prompt | What it does |
| Kicks off the Root Cause Analysis workflow (Perspective → Inversion → Decomposition → Meta-Systems) against your problem. |
| Kicks off the Strategy Design workflow. |
| Kicks off the Decision Making workflow. |
| Open-ended: calls |
| Applies one specific model (e.g. |
Direct URI-based access to models and transformations:
hummbl://model/{code} – Individual model (e.g., hummbl://model/P1)
hummbl://transformation/{type} – All models in transformation (e.g., hummbl://transformation/P)
hummbl://models – Complete Base120 framework
hummbl://methodology/self-dialectical-ai – Structured Self-Dialectical AI methodology definition
hummbl://methodology/self-dialectical-ai/overview – Markdown overview of the methodology for quick operator reference
The HUMMBL Self-Dialectical AI Systems methodology (v1.2) enables ethical self-correction via five dialectical stages (thesis, antithesis, synthesis, convergence, meta-reflection) mapped to Base120 mental models plus SY meta-models. Use the tools/resources above to fetch the canonical JSON definition, Markdown overview, or to audit references in external documents.
HUMMBL includes pre-defined problem patterns that map common challenges to recommended transformations and models. See Problem Patterns Documentation for the complete catalog with detailed guidance.
git clone https://github.com/hummbl-dev/mcp-server.git
cd mcp-server
npm installnpm run buildnpm run devnpm run typechecksrc/
├── index.ts # stdio entry point
├── server.ts # Server configuration
├── framework/
│ └── base120.ts # Complete mental models database
├── tools/
│ └── models.ts # Tool registrations
├── resources/
│ └── models.ts # Resource endpoints
├── types/
│ └── domain.ts # Core type definitions
└── utils/
└── result.ts # Result pattern utilitiesThe REST API is self-documenting via OpenAPI 3.0. Fetch the spec from:
GET https://api.hummbl.io/openapi.jsonImport it into Postman, Insomnia, Hoppscotch, Swagger UI, or any OpenAPI-compatible client. No authentication is required to read the spec.
This repo is part of the HUMMBL cognitive AI architecture. Related repos:
Repo | Purpose |
Authoritative reference for the 120 mental models served by this MCP server | |
First-party governance integration used by this repository's Python governance package | |
Agent-aware code quality scoring and attribution | |
Stdlib-only safety patterns for agentic AI systems | |
Assured Agentic Architecture — validation-first assurance |
Learn more at hummbl.io.
The governance package is a HUMMBL-owned integration and discovery path. It is not independent validation or evidence of external adoption.
The HUMMBL MCP Server operates locally on your machine and does not collect, transmit, or store any personal data. All processing happens entirely within your local environment.
The server reads mental models framework data from its internal database
Problem descriptions and user inputs are processed locally to generate model recommendations
No data is sent to external servers or third-party services
No telemetry or analytics are collected
No persistent storage of user inputs or problem descriptions
All processing is ephemeral and happens in memory
No logs or audit trails are retained beyond the current session
We do not share any data with third parties
The server does not make network requests except for MCP protocol communication with Claude Desktop
No data is transmitted to HUMMBL servers or any external services
No data is retained after processing
All data is cleared from memory when the server process terminates
No historical records or user data are stored
For privacy-related questions or concerns, contact: privacy@hummbl.io
Apache 2.0 © HUMMBL, LLC
1.2.0
See docs/REPO_HEALTH.md for health contract, validation commands, canonical source, and branch-protection expectations.
Add a relationship between two mental models with evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| source_code | Yes | Source model code | |
| target_code | Yes | Target model code | |
| relationship_type | Yes | Type of relationship (e.g., 'enables', 'reinforces') | |
| confidence | Yes | Confidence level: A=High, B=Moderate, C=Hypothesis | |
| evidence | No | Evidence supporting this relationship |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| relationship | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only says 'Add' without details on idempotency, side effects, or permissions. Does not clarify if evidence is required or optional (it is optional per 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?
The description is a single, clear sentence with no wasted words. It is efficiently front-loaded.
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 5 parameters, including enums and patterns, and no annotations, the description lacks sufficient context for confident use. It omits behavioral details and usage context, though output schema exists.
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 descriptions for all parameters. The tool description adds no extra meaning beyond the schema. 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 clearly states the action 'Add a relationship' between mental models with evidence. It is specific and distinguishes from siblings like 'get_related_models' which retrieves rather than creates.
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?
No guidance is provided on when to use this tool versus alternatives, such as 'get_related_models' or when to add relationships. Missing context like prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit a list of HUMMBL model references for existence, transformation alignment, and duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
| Name | Required | Description |
|---|---|---|
| methodologyId | Yes | |
| documentVersion | Yes | |
| totalReferences | Yes | |
| validCount | Yes | |
| invalidCount | Yes | |
| issues | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions checking existence, alignment, and duplicates, but does not disclose side effects, error handling, or whether it is read-only. The transparency is minimal.
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, fully front-loaded sentence. It is appropriately sized with no fluff or redundancy.
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 tool has a nested parameter and an output schema, but the description does not mention the return value, error scenarios, or any prerequisites. Information is incomplete for an agent to understand the tool's full 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 description does not explain any parameters. The input schema has a complex nested structure, but the description adds no meaning beyond what the schema provides. Given low schema description coverage, this is a significant gap.
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 (audit), the resource (HUMMBL model references), and the scope (existence, transformation alignment, duplicates). It is specific and distinguishes from sibling tools like get_model or list_all_models.
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 one has a list of model references to check, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Proceed to the next step of your guided workflow after completing the current step.
| Name | Required | Description | Default |
|---|---|---|---|
| workflow_name | Yes | Which workflow you're working on | |
| current_step | Yes | Current step number | |
| step_insights | Yes | Your insights or outputs from completing the current step | |
| session_id | No | Session ID if using state persistence |
| Name | Required | Description |
|---|---|---|
| workflow | Yes | |
| displayName | Yes | |
| currentStep | Yes | |
| totalSteps | Yes | |
| transformation | Yes | |
| guidance | Yes | |
| suggestedModels | Yes | |
| questions | Yes | |
| nextAction | Yes | |
| completed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose side effects, validation, or state changes beyond 'proceed to next step'.
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 sentence with 15 words, conveying the core purpose without any waste.
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 presence of an output schema and full parameter descriptions, the description is adequate but lacks context on return values or workflow state management.
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?
All parameters have descriptions in the schema (100% coverage), so the description adds no additional meaning. 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 clearly states the verb ('Proceed') and resource ('guided workflow'), and distinguishes itself from siblings like start_workflow and list_workflows.
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 after completing a step ('after completing the current step'), but does not explicitly exclude other scenarios or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a curated subset of Base120 mental models as Markdown, JSON, or PDF. Pass codes for a specific list, transformation for a whole group, or neither for all 120.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | Output format: 'markdown', 'json', or 'pdf'. | |
| codes | No | Optional list of model codes (e.g. ['P1','IN3','CO5']). Takes precedence. | |
| transformation | No | Optional transformation key (P, IN, CO, DE, RE, SY) to export a whole group. |
| Name | Required | Description |
|---|---|---|
| format | Yes | |
| modelCount | Yes | |
| missingCodes | Yes | |
| content | Yes | |
| byteLength | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the burden of behavioral transparency. It states the action is 'Export' which implies a read-only operation, but it does not explicitly confirm side-effect-free behavior, authentication requirements, or any potential limitations. The description is adequate but lacks explicit safety or behavioral context beyond the obvious.
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 two sentences with no extraneous information. The first sentence states the core function and formats, the second explains parameter usage. Every word is necessary and front-loaded.
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 presence of an output schema (indicated by the signal), the description does not need to detail return values. It covers all selection modes and required input. Minor omission: no mention of limits on the number of codes, but not critical for a curated subset export.
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 100%, but the description adds significant value by explaining the interaction between the optional parameters (codes takes precedence, transformation vs. all). This clarifies the logic beyond what individual parameter descriptions provide.
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 exports mental models in three formats (Markdown, JSON, PDF) and distinguishes three modes of selection (codes list, transformation group, or all 120). This verb+resource+variation is specific and differentiates from sibling tools which focus on relationships, recommendations, etc.
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 explains when to use each parameter: 'Pass `codes` for a specific list, `transformation` for a whole group, or neither for all 120.' This provides clear context. It does not explicitly exclude sibling tools, but the sibling set is diverse enough that this is the only export tool, so no confusion is likely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover which workflow best fits your problem type or situation.
| Name | Required | Description | Default |
|---|---|---|---|
| problem_keywords | Yes | Keywords describing your problem (e.g., 'failure', 'strategy', 'decision') |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| matchCount | Yes | |
| recommendations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'discover which workflow best fits' but does not explain how the discovery works, what criteria are used, or any side effects. With no annotations, the description carries full burden for transparency, and it falls short.
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, well-formed sentence that directly conveys the tool's purpose. It is concise and front-loaded, but could be slightly expanded without harming brevity.
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?
Despite having only one parameter and no output schema details visible, the description omits important contextual information such as how results are returned, the matching algorithm, or differentiation from sibling tools like search_problem_patterns. The presence of an output schema is not leveraged in the description.
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 already provides a clear description for the only parameter, problem_keywords, with examples. The tool description adds no further semantic value beyond the schema, 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 clearly states the tool discovers the best workflow for a given problem type, using a specific verb (discover) and resource (workflow). It distinguishes itself from siblings like list_workflows or search_problem_patterns by focusing on problem-to-workflow matching.
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?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like list_workflows or search_problem_patterns, nor does it specify prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the canonical Self-Dialectical AI Systems methodology with HUMMBL Base120 mappings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| title | Yes | |
| version | Yes | |
| summary | Yes | |
| documentUrl | No | |
| totalPages | No | |
| modelsReferenced | Yes | |
| stages | Yes | |
| metaModels | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation ('Retrieve') but does not disclose any behavioral traits such as auth requirements, rate limits, or whether it returns metadata. It is adequate but not comprehensive.
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?
A single, well-structured sentence that immediately conveys the tool's purpose. No redundant or extraneous 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 simple retrieval tool with no parameters and an output schema, the description is fairly complete. It names the specific resource and mentions the mappings. However, it lacks usage context, such as when to prefer this over similar tools.
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 tool has 0 parameters, so schema coverage is 100%. The description adds meaning by specifying what is retrieved (the methodology and mappings), which goes beyond the empty 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 verb 'Retrieve' and specifies the resource: 'the canonical Self-Dialectical AI Systems methodology with HUMMBL Base120 mappings'. This distinguishes it from sibling tools like get_model or get_transformation, which retrieve different resources.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve detailed information about a specific HUMMBL mental model using its code (e.g., P1, IN3, CO5).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Model code (e.g., P1, IN3, CO5) |
| Name | Required | Description |
|---|---|---|
| code | Yes | |
| name | Yes | |
| definition | Yes | |
| priority | Yes | |
| transformation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose read-only nature and any constraints. It only states 'Retrieve detailed information,' which is implied but does not explicitly confirm no side effects or limitations such as rate limits.
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 sentence, concise and front-loaded. It could be slightly more structured (e.g., bullet points) but is efficient and contains no superfluous 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?
Given the tool's simplicity (one required parameter, output schema present), the description provides enough context for an AI agent to use it. However, it could mention that detailed information is returned, though the output schema likely covers that.
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 already provides a pattern and description for the 'code' parameter. The description adds example codes, but with 100% schema coverage, it offers no substantial new 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 verb 'Retrieve,' the resource 'HUMMBL mental model,' and the identifier 'code.' It differentiates from siblings like 'list_all_models' and 'get_related_models' by focusing on a single model by code.
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?
While the description implies use when you have a specific code (e.g., P1, IN3, CO5), it lacks explicit guidance on when not to use it or mentions of alternatives like 'search_models' or 'list_all_models' for broader queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the caller's past recommendation calls (problems submitted and the model codes that were returned), newest first. Useful for 'what did we explore last time?' and for avoiding re-recommending the same models.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows to return (default 20, max 100) | |
| offset | No | Pagination offset (default 0) |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| limit | Yes | |
| offset | Yes | |
| recommendations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates this is a read operation (fetch) and specifies ordering ('newest first'). However, without annotations, it omits other behavioral aspects such as whether authentication is required, rate limits, or fallback behavior for empty history. The bar is higher due to no 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?
Two sentences: one for function, one for use case. Every word adds value with no redundancy or irrelevant detail.
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 output schema exists, the description does not need to detail return format. It covers purpose, content, ordering, and use cases. The two parameters are fully documented in the schema, and the description completes the picture.
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 for 'limit' and 'offset'. The description adds no parameter-specific details beyond the schema and a note on ordering. Per guidelines, high coverage allows a baseline of 3.
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 a specific verb ('Fetch'), names the resource ('past recommendation calls'), and details the content ('problems submitted and the model codes that were returned'). This clearly distinguishes it from siblings like 'recommend_models' and 'list_all_models'.
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 states two use cases: 'what did we explore last time?' and avoiding re-recommending the same models. While it does not list when not to use or alternative tools, the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve information about a specific transformation type and all its models (P, IN, CO, DE, RE, SY).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Transformation key (P, IN, CO, DE, RE, or SY) |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| name | Yes | |
| description | Yes | |
| modelCount | Yes | |
| models | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits like read-only nature, authentication requirements, or error handling. The tool is a read operation but not stated.
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 of moderate length, no fluff, though could be slightly more concise. Front-loaded with action and resource.
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 tool with one parameter and an existing output schema, the description adequately states what is retrieved. Missing context about the meaning of transformation types or models, but acceptable given 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?
Schema coverage is 100% with the parameter 'key' having a clear enum and description. The description restates the enum values, adding minimal new 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 specifies the verb 'retrieve', the resource 'transformation type and all its models', and lists the model keys. It clearly distinguishes from siblings like 'get_model' which retrieves a single model.
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?
No explicit guidance on when to use this tool versus alternatives such as 'get_model' or 'list_all_models'. The use case is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve complete list of all 120 HUMMBL mental models with basic information.
| Name | Required | Description | Default |
|---|---|---|---|
| transformation_filter | No | Optional filter by transformation type |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| models | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must compensate. It mentions 'basic information' but does not specify what fields are included, nor any limits or performance traits. The lack of detail leaves behavioral assumptions unclear.
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, front-loaded with the key action, no wasted words. Highly concise and to the point.
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 one optional filter and an output schema, the description is adequate. It could mention return format specifics, but output schema fills that gap. Minor lack of detail about 'basic information'.
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 a clear description for the only parameter (transformation_filter). The tool description adds no additional meaning, but baseline 3 is appropriate given full schema documentation.
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 'Retrieve complete list of all 120 HUMMBL mental models', using a specific verb and resource, and distinguishes itself from siblings like search_models (filtered) and get_model (single).
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?
No guidance is provided on when to use this tool versus alternatives like search_models for filtered results, or get_model for detailed info. Missing context on suitability for full vs partial listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available guided workflows for problem-solving with Base120 mental models.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| workflows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. While 'get' implies a read-only operation, the description does not explicitly state safety, idempotency, or that no state changes occur. It also does not mention any prerequisites or side effects. Although the tool has no parameters, the behavioral transparency is only adequate.
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, clear sentence with no extraneous information. It is front-loaded and efficient, 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 simplicity of the tool (no parameters, output schema exists), the description is mostly complete. It could optionally mention that the output is a list of workflow names/IDs, but that is likely covered by the output schema. Minor room for improvement.
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 no parameters and schema description coverage is 100%. According to the rule, 0 parameters yields a baseline of 4. The description adds no parameter-specific information, but none is needed as there are no 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 retrieves all available guided workflows for problem-solving with Base120 mental models. It uses a specific verb ('get') and resource ('available guided workflows'). It distinguishes from sibling 'find_workflow_for_problem' which likely filters by problem, making the scope clear.
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 for obtaining a full list of workflows, but does not explicitly provide guidance on when to use this tool versus alternatives like 'find_workflow_for_problem'. No when-not-to-use or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recommended mental models based on a natural language problem description using HUMMBL REST API.
| Name | Required | Description | Default |
|---|---|---|---|
| problem | Yes | Detailed description of the problem or challenge |
| Name | Required | Description |
|---|---|---|
| problem | Yes | |
| recommendationCount | Yes | |
| recommendations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, potential delays, or side effects. The mention of 'HUMMBL REST API' hints at an external call but adds no actionable 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 short but includes a redundant second sentence about the API implementation. While efficient, it contains unnecessary detail that does not aid an AI agent.
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 single parameter and existence of an output schema, the description is minimally sufficient. However, it lacks explanation of how recommendations are generated or what the output contains beyond 'recommended mental models'.
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 a clear description for the only parameter. The description adds 'natural language' but does not significantly enhance understanding 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 retrieves recommended mental models based on a problem description. It distinguishes from siblings like list_all_models and search_models by focusing on recommendations from natural language input.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., search_problem_patterns or find_workflow_for_problem). The description only implies usage for problem descriptions but lacks when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search HUMMBL mental models by keyword across codes, names, and definitions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (minimum 2 characters) |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| resultCount | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It specifies the fields searched (codes, names, definitions) but does not mention whether the search is case-sensitive, returns partial matches, or handles pagination. It also does not state that it is read-only. The presence of an output schema partially offsets the lack of return format details.
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 sentence with no redundant words. It efficiently conveys the essential purpose and scope.
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 single-parameter search tool with an output schema, the description is largely complete. It covers the action, resource, and search fields. However, it could mention additional context such as case-insensitivity or result ordering to prevent misuse.
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 covers the 'query' param with 100% coverage, but the description adds meaning by specifying which fields are searched (codes, names, definitions). This helps the agent understand the search scope beyond what the schema provides.
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 (search by keyword), the resource (HUMMBL mental models), and the scope (across codes, names, and definitions). It differentiates from siblings like 'get_model' (specific model retrieval) and 'search_problem_patterns' (different entity).
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?
No explicit guidance on when to use this tool versus siblings such as 'search_problem_patterns', 'get_model', or 'list_all_models'. The description only implies usage for keyword-based search but fails to mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find pre-defined problem patterns with recommended transformations and top models based on a search query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (minimum 2 characters) |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| patternCount | Yes | |
| patterns | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states it finds patterns and recommendations, without disclosing whether the operation is read-only, requires authentication, or any pagination or sorting behavior.
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 clear sentence with no extraneous words. Front-loaded with the action and resource.
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 tool has an output schema, so return values are documented elsewhere. For a simple search with one parameter, the description sufficiently explains what is returned. Minor gaps exist but overall adequate given low complexity.
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 adequate description of the 'query' parameter. The tool description adds context about the nature of results (pre-defined patterns, recommended transformations, top models), but does not add further semantic detail to 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 it finds pre-defined problem patterns with associated transformations and models. It distinguishes from sibling tools like 'search_models' and 'recommend_models' by focusing on patterns rather than directly on models or workflows.
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?
No guidance on when to use this tool versus alternatives like 'search_models' or 'find_workflow_for_problem'. The description implies use for problem pattern search, but does not specify when not to use it or provide explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Begin a guided multi-turn workflow for systematic problem-solving using Base120 mental models.
| Name | Required | Description | Default |
|---|---|---|---|
| workflow_name | Yes | Which workflow to start | |
| problem_description | Yes | Brief description of your problem or goal | |
| session_id | No | Optional session ID for state persistence |
| Name | Required | Description |
|---|---|---|
| workflow | Yes | |
| displayName | Yes | |
| problemDescription | Yes | |
| currentStep | Yes | |
| totalSteps | Yes | |
| transformation | Yes | |
| guidance | Yes | |
| suggestedModels | Yes | |
| questions | Yes | |
| nextAction | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions 'multi-turn' but fails to explain that the tool returns a session_id for continuation, the expected follow-up calls, or any side effects. A guided workflow initiation requires more behavioral context.
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 sentence that is front-loaded with the key action and purpose. No unnecessary words, making it concise and to the point.
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 of a guided multi-turn workflow, the description is incomplete. It does not explain the return value (despite an output schema existing), how to continue the workflow, or what to expect after starting. The presence of sibling tools like continue_workflow implies a sequence, but the description does not connect them.
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 100%, so baseline is 3. The description adds no additional meaning to the parameters beyond what the schema provides, such as elaborating on the enum values or the format of problem_description.
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 verb 'Begin', the resource 'workflow', and specifies it is a guided multi-turn process using Base120 mental models. It distinguishes from sibling tools like continue_workflow and list_workflows.
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 for starting a workflow but does not explicitly state when to use versus alternatives like continue_workflow or list_workflows. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct action or query (e.g., get vs search vs recommend, add vs audit). Even closely related tools like get_model and get_related_models have clearly different purposes. No overlapping functionality.
All tools follow a verb_noun snake_case pattern (e.g., add_relationship, export_models, start_workflow). Verbs are descriptive and consistently used. No mixed conventions or ambiguous names.
With 16 tools covering models, relationships, workflows, recommendations, search, and export, the count is well-scoped. Each tool has a clear role, and the set is neither bloated nor sparse for a methodology server.
The tool set covers core CRUD-like operations (retrieve, list, search, add, export) and workflow management. Minor gaps exist, such as no tools for updating or deleting relationships, but the domain's static nature makes these non-critical.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Curated knowledge API for AI agents - skill packs, semantic search, validated patterns.
Search, retrieve, create, and update visual knowledge maps in a user's KnowMapped account.
Read-only tools over the Safer Agentic AI framework: 238 patterns + 14 heuristics.
Turn grounded AI answers into trusted comparisons, plans, timelines, and decision views.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hummbl-io/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
