Skip to main content
Glama

BizClaw Business Directory MCP

Search Companies

search_companies
Read-onlyIdempotent
Search for companies in the BizClaw business directory.
Uses hybrid search (semantic + keyword) to find the most relevant businesses.
Returns lightweight summaries to save tokens. Use get_company(id) for full details (contact, pricing, features, etc.).

Args:
    query: Natural language search query (e.g. "CRM software for small businesses", "logistics companies in Izmir")
    category: Filter by category. Use list_categories to see available options.
    country: Filter by country (e.g. "Turkey", "United States", "Germany")
    city: Filter by city (e.g. "Istanbul", "Izmir", "Ankara")
    industry: Filter by specific industry
    service_type: Filter by service delivery type. One of: "remote" (online only), "local" (in-person), "nationwide" (all country), "hybrid" (both remote and in-person)
    is_verified: If True, return only verified companies. If False, return only unverified. Omit to return all.
    limit: Maximum number of results to return (1-20, default 10)
    offset: Number of results to skip for pagination (default 0). Use with limit to get next pages.

Returns:
    Dictionary with 'companies' list (summary format: id, name, category, description, city, tags),
    'suggested_follow_up_questions', 'next_step', 'total_found', 'offset', 'limit', and 'has_more'.
    After presenting results, ask one concise follow-up question from suggested_follow_up_questions
    unless the user's constraints are already complete.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoOptional city filter, for example Istanbul, Izmir, Ankara, or Berlin.
metaNoOptional UCP request metadata. Use {'ucp-agent': {'profile': 'https://agent.example/.well-known/ucp'}} for UCP-aware negotiation.
limitNoMaximum number of results to return. Use 1-20 for searches and 1-100 for proposal lists.
queryYesNatural language search query describing the company, service, category, or buying intent.
offsetNoPagination offset. Increase with limit to fetch later pages.
countryNoOptional country filter, for example Turkey, United States, or Germany.
categoryNoOptional BizClaw business category filter. Use list_categories when unsure.
industryNoOptional specific industry or vertical filter.
is_verifiedNoOptional verification filter. True returns verified companies only; false returns unverified companies only.
service_typeNoOptional service delivery type: remote, local, nationwide, or hybrid.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds non-obvious behavioral context: hybrid search, lightweight summary format, pagination via limit/offset and has_more, and the instruction to ask a follow-up question unless constraints are complete. 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.

Conciseness4/5

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

The description is well-structured with Args and Returns sections and front-loads purpose and search method. It is longer than strictly necessary because it partly repeats schema parameter descriptions, but each paragraph adds examples and output-handling guidance, so it remains organized.

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

Completeness5/5

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

Despite having an output schema, the description fully explains return fields, pagination, and follow-up behavior, and covers all filters. The only schema parameter not listed in the Args section is meta, which is already documented in the schema; nothing critical is missing for correct invocation and result handling.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description goes beyond the schema with concrete query examples, enumerated service_type meanings, tri-state is_verified behavior, limit bounds, and offset pagination. It omits the meta parameter, but that parameter's schema description covers it, so the addition is still strong.

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

Purpose5/5

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

The description states a specific verb and resource: 'Search for companies in the BizClaw business directory.' It also differentiates itself from siblings by noting it returns lightweight summaries and directing users to get_company(id) for full details, making the tool's purpose unambiguous.

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

Usage Guidelines5/5

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

The description explicitly provides alternatives and conditions: 'Use get_company(id) for full details' and 'Use list_categories to see available options.' This clearly tells an agent when to use search versus other tools and when to switch to get_company or list_categories.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Most tools target clearly distinct actions: searching, retrieving company details, creating proposals, and replying. The main potential confusion is between search_companies and ask_about_companies, and between create_proposal and create_batch_proposals, but their descriptions clarify the intended use cases well.

Naming Consistency4/5

Tool names mostly follow a consistent snake_case verb_noun pattern like search_companies, get_company, create_proposal, and reply_to_proposal. ask_about_companies deviates slightly from the pattern but is still readable and predictable.

Tool Count5/5

Nine tools is well-scoped for a business directory MCP server covering discovery, company lookup, and proposal management. Each tool has a distinct role and no tool feels redundant or unnecessary.

Completeness4/5

The tool surface covers the core workflow well: search companies, get details, create proposals individually or in batch, list proposals, and reply to company responses. Minor gaps exist—such as no explicit cancel/update proposal or direct proposal-by-ID lookup—but these are not blocking for typical usage.

Resources