Kooga

Read AI visibility

readScorecard

Read-onlyIdempotent

How often AI engines mention this brand, per engine and over time: series has a point per engine and per day, week or month (interval). byCountry splits the period by the country the engines are asked from; country keeps one. For what the engines actually said, readAnswers.

Only for a workspace that tracks its AI visibility (it has tracked prompts).

Input Schema

Name	Required	Description	Default
`to`	No	Last day of the range, YYYY-MM-DD, today at the latest; a range is two years at most
`days`	No	Reporting window in days
`from`	No	First day of a custom range, YYYY-MM-DD. With `to`, it takes the place of `days`
`scope`	No	Unbranded prompts are the ones where a mention means the engine CHOSE to bring the brand up - the honest measure	unbranded
`country`	No	Only prompts asked from this country, as a two-letter code (a prompt's persona sets where it is asked from)
`interval`	No	How far apart the points of `series` are; left out: daily up to 30 days, weekly up to 90 days, monthly beyond
`workspaceId`	No	The workspace, as listWorkspaces gives it (its id or slug). Leave it out when this connection reaches one workspace.

Output Schema

Name	Required	Description
`scope`	Yes
`series`	Yes	One point per period and engine, oldest first: engines are checked on different days
`totals`	Yes	The whole period, every engine
`branded`	Yes	How the engines answer prompts that name the brand, whatever `scope` is
`country`	Yes	The country the figures are kept to; null for every country
`byEngine`	Yes
`interval`	Yes	How far apart the points of `series` are
`byCountry`	Yes	The period in each country the engines are asked from, most answers first; every country, whatever `country` is
`sentiment`	Yes	How the answers that name the brand speak of it
`promptCounts`	Yes	Active tracked prompts
`untrackedBrands`	Yes	Brands the answers name that are not tracked competitors
`verifiedSamples`	Yes	Answers read by the check that confirms which brand is meant
`lowSampleEngines`	Yes	Engines with too few answers in the period to rely on

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 27, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered. The description adds real context beyond them: the tracked-prompts precondition, the note that unbranded prompts are the 'honest measure', and the default bucketing behavior implied by `interval`.

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?

Two tightly packed paragraphs — metric description first, alternative and precondition last. No filler, though the sentence about `byCountry`/`country` is dense enough to require a second read.

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?

An output schema exists, so return values needn't be explained, and the description still sketches the result shape. With 7 optional params, all schema-documented, plus a stated precondition, an agent has what it needs to call correctly.

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%, so every parameter is already documented with patterns, enums and defaults. The description largely restates that (`interval`, `country`, `series`) rather than adding new syntax or edge cases, so the baseline 3 applies.

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?

Opens with a specific measure — how often AI engines mention the brand — and names the exact return shape (`series` per engine and time bucket, `byCountry`, `country`). It also distinguishes itself from the sibling `readAnswers` ('for what the engines actually said'), so an agent can route without inspecting schemas.

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?

States a prerequisite ('Only for a workspace that tracks its AI visibility (it has tracked prompts)') and points to `readAnswers` for verbatim answers. There is no explicit exclusion list beyond that, but the conditioning and alternative routing are clear.

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

All Kooga tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?