Skip to main content
Glama
ellmos-ai

ellmos-homebase-mcp

Official

hb_api_discover

Auto-detect API schema from a base URL to map available endpoints and requests, so you can integrate APIs without manual inspection.

Instructions

Auto-detect API schema from a base URL

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL to inspect.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0-alpha.29

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. 'Auto-detect' implies an outbound network call to a user-supplied URL, but the description does not disclose whether it performs a live request, what it does on failure, whether authentication is needed, or what format the detected schema takes. With zero annotation coverage this is a significant gap.

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

Conciseness4/5

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

A single front-loaded sentence with no filler, appropriate for a one-parameter tool. It is efficient, though the terseness leaves it short of the 'complete' end of the scale.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations, no output schema, and many similarly named siblings, the description is too thin. It does not explain return shape, error behavior, or how it differs from hb_plug_discover, leaving key agent decisions ungrounded.

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

Parameters3/5

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

Schema coverage is 100% (the single url parameter is documented), so the baseline is 3. The description adds no meaning beyond the schema, e.g. whether the URL must be reachable, include a scheme, or point to an OpenAPI/GraphQL endpoint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Auto-detect API schema') and its input ('from a base URL'), which is clear enough on its own. However, it does not distinguish this tool from the closely named sibling hb_plug_discover or from hb_api_probe/hb_api_export, all of which appear to touch API-schema concepts. Without that differentiation an agent must infer which discovery tool to use.

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

Usage Guidelines2/5

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

There is no indication of when to use hb_api_discover versus hb_plug_discover, hb_api_probe or hb_api_export. No prerequisites, exclusions, or context are given, so the agent gets no routing guidance.

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