Skip to main content
Glama

MisarSEO MCP Server

get_google_business_questions

Fetches question-and-answer rows for one business keyword. Run this only when Q&A evidence is needed. THE TWO PROVIDERS RETURN DIFFERENT THINGS AND YOU MUST SAY WHICH YOU HAVE. On the paid data provider these are real Google Business Profile questions and answers for a profile near near, and it CHARGES CREDITS. On the default free provider they are Google/Bing autocomplete completions reframed as questions — real search phrasings, but NOT anybody's Business Profile Q&A, with no answers and no asker — and NOTHING IS CHARGED. Never attribute a free-provider row to a business or quote it as a customer's question. near IS IGNORED ON THE FREE PROVIDER: the suggest APIs take no geography, so the same keyword returns the same rows from any coordinate. It is required because the paid provider needs it, not because the result is always localised. On the paid provider radiusKm is converted to metres and clamped into 200 m - 199,999 m, so a radius above about 200 km is silently reduced to that ceiling. An empty result means no Q&A was found for this phrasing; whether the business has questions elsewhere was not measured.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nearYesCoordinate and radius to search around.
depthNoMaximum Q&A rows to fetch (1-100). Defaults to 20.
keywordYesBusiness name or search phrase identifying the Google Business Profile.
projectIdYesRequired. The MisarSEO project ID to scope this call to. Get one from list_projects.
languageCodeNoLanguage code (e.g. 'en', 'es', 'fr'). Omit it to use the project's default market language, which falls back to 'en'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: it warns that the paid provider CHARGES CREDITS and the free provider does not, that the two providers return fundamentally different data, that `near` is silently ignored on the free provider, and that radius is clamped to 0.2-200 km. It also cautions against misattributing free-provider rows, which aligns with (rather than contradicts) readOnlyHint=false for a credit-consuming call.

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

Conciseness5/5

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

Front-loaded with purpose and the call gate, then provider divergence, then parameter caveats, then empty-result meaning. Despite its length, every sentence carries decision-relevant information with no filler.

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?

With no output schema, the description competently covers what rows mean on each provider and what an empty result implies. It could go slightly further in describing the returned row fields (answers, asker, timestamps), but the substantive gaps are covered.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description adds real meaning: it explains why `near` is required despite being ignored on the free provider, and details the radius clamping/unit conversion beyond what the schema states. This is value beyond the structured fields, not repetition.

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+resource (fetch question-and-answer rows for one business keyword) and immediately scopes it with two distinct provider behaviors. An agent can tell this apart from the many get_gbp_* siblings because it is explicitly about Q&A evidence, not profile, reviews, or performance.

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

Usage Guidelines4/5

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

"Run this only when Q&A evidence is needed" gives a clear when-to-use gate and an implicit exclusion, plus provider-selection guidance. It does not name a specific alternative tool to use instead, so it falls just short of full when/when-not/alternatives coverage.

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.