Skip to main content
Glama
Sign In
Octen-Team

octen-mcp

Official
by Octen-Team
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Business Search

business_search
Read-only

Look up companies or people and return structured profile cards with financials, key people, career history, and ranked sources for due diligence and comparison.

Instructions

Look up a company or a person and get a structured card back, plus the ranked sources behind it. A company card carries the profile, identifiers, financial and stock metrics, key people and recent announcements; a person card carries the current position, career history and recent activity. Name two companies in one query and you get a card for each, same fields, ready to compare. Set entities.enable to false for a plain ranked list instead.

USE FOR any question about a company or the people in one, including the numbers: revenue, net income, gross profit by quarter and year, share price and 52-week range, funding rounds and who led them, headcount and web traffic, key people and their titles, career history, recent announcements. Also "what does this company do", due diligence, and how two of them compare.

The card already holds those figures, so a question like "what was their revenue last quarter" is one call here. Reaching for search means reading a dozen pages for numbers this returns directly, and far more context for the same facts.

NOT FOR breaking coverage of an event — use news_search, which returns articles and storylines. NOT FOR general web pages — use search.

Examples: "NVIDIA company overview", "Lisa Su AMD CEO", "compare Stripe and Adyen payment processing", "semiconductor supply chain outlook".

keywords: company, business, due diligence, competitor, executive, CEO, founder, funding, valuation, revenue, earnings, stock, profile, who is, what does company do, compare companies

Input Schema

NameRequiredDescriptionDefault
countNoNumber of results to return (1-100). Default 5.
queryYesNon-empty search query. Max 500 chars.
timeoutNoRequest timeout in seconds (1-60). Defaults to 30s if unset.
end_timeNoUpper bound for the time window, ISO 8601.
entitiesNoThe company and person cards. On by default — omit to use the server default, or disable for a plain ranked list. The domain, time and language filters apply to the ranked results only, never to the cards.
languageNoLanguages to filter results by, as ISO 639-1 codes. Empty = no filter.
highlightNoReturn a ranked highlighted snippet per result. Omit to use the server default.
start_timeNoLower bound for the time window, ISO 8601 (e.g. '2025-01-01T00:00:00Z').
time_basisNoWhich timestamp the time window filters against: page `published` date, last `crawled` date, or `auto`. Default auto.auto
time_rangeNoRelative time window (e.g. `week`, `month`). Mutually exclusive with `start_time`/`end_time` — if both are given, the absolute range wins.
full_contentNoReturn the cleaned full page body per result. Heavier than `highlight` — use only when the snippet isn't enough. Omit to use the server default (off).
exclude_domainsNoDrop results from these domains. Max 1200, each ≤60 chars.
include_domainsNoOnly return results from these domains (e.g. 'arxiv.org'). Max 1200, each ≤60 chars.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds real behavioral context beyond that: entities are on by default and disabling them yields a plain ranked list, and the domain/time/language filters apply only to ranked results, never to the cards. It stops short of discussing rate limits, latency, or ordering of cards vs. results, so it is strong but not exhaustive.

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?

Well front-loaded: what it returns first, then USE FOR, NOT FOR, examples, and keywords. It is long and the performance argument ('reading a dozen pages') is repeated implicitly, but every block serves retrieval or selection, so only mild trimming is warranted.

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

Completeness4/5

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

For a 13-parameter tool with nested objects and no output schema, the description supplies the return-value shape (card fields per entity type) and the card-vs-ranked-list distinction, which is the hard part. The remaining parameters are fully documented in the schema, so the only gap is explicit guidance on result ordering and pagination.

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, but the description adds meaning the schema does not: naming two companies in one query produces one card each with identical fields 'ready to compare', and `entities.enable=false` switches to a plain ranked list. It does not touch highlight/full_content/count tradeoffs, which the schema already documents.

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?

States a specific verb and resource ('look up a company or a person') and describes the exact return shape: a structured card plus ranked sources, with the fields each card type carries. It explicitly differentiates itself from siblings search and news_search, so an agent can pick it without opening any schema.

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?

Has explicit USE FOR (with a long list of qualifying question types and figures) and NOT FOR clauses routing event coverage to `news_search` and general pages to `search`. Four concrete example queries and the 'compare two companies' pattern remove nearly all ambiguity about when to select this tool.

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

Deploy Server

Other Tools