Skip to main content
Glama
Sign In
Unilytics MCP Server

Unilytics MCP Server

Official
by TeamUnilytics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

get_project_config

Read-only

Retrieve a project's saved client settings—brand domain, competitors, industry, keywords, and locations—for tasks that need existing project-specific values.

Instructions

Return a project's stored client settings: brand domain, competitors, industry, tracked keywords, locations.

Use when a skill or task needs client-specific values: these are the settings the user already
saved for the project. Fields with no value yet are listed under `missing`; set_project_config
stores skill-specific values.

Returns brand/competitor/industry config plus `custom` (skill-specific config
saved by set_project_config, namespaced per skill). The first 50 namespaces by name are listed
(`custom_total` counts them all when there are more). When the custom config is large, some
namespaces are listed as {"omitted": true, "chars": n} and `custom_omitted` names them; pass
`namespace` to read one of them (a very large one comes as JSON text in pages: `namespace_json`
with `next_cursor`, passed back as `cursor`). Keyword, competitor and location lists return their
first entries (up to 300, fewer when they are long) with a `*_total` count. Long text fields end
in "…"; a value too large to return (domain, aeo) is null and named with its size in
`omitted_fields`.

Args:
    project_id: The project to load config for (from list_projects()).
    namespace: Optional: return only this namespace of the custom config.
    cursor: next_cursor from a previous call, for the next page of a large namespace.

Input Schema

NameRequiredDescriptionDefault
cursorNo
namespaceNo
project_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavior the annotations cannot: empty fields surface under `missing`, custom config is namespaced per skill with the first 50 listed, oversized namespaces return as `{omitted:true, chars:n}`, list fields truncate at 300 with `*_total` counts, and long text ends in "…". This is exactly the truncation/pagination behavior an agent needs and cannot infer.

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?

Purpose is front-loaded, then usage, then return-shape, then args — a sound order. There is mild redundancy in that namespace and cursor are explained in the prose and then again in the Args block, but the length is justified by the genuinely complex return shape.

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?

With no output schema, the description carries full responsibility for describing returns, and it covers the normal payload, truncation, omission markers, totals, and the two-stage pagination path. Nothing an agent needs in order to call it or interpret a response is missing.

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 description coverage is 0%, so the description must carry all three parameters, and it does: project_id is sourced "from list_projects()", namespace restricts output to one custom namespace, and cursor is the `next_cursor` from a prior call. Each parameter's role in the pagination flow is explained, not just restated.

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?

"Return a project's stored client settings" names a specific verb and resource, then enumerates the contents (brand domain, competitors, industry, tracked keywords, locations). It also implicitly separates itself from the writing sibling set_project_config, so an agent can tell what it gets without opening the schema.

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?

"Use when a skill or task needs client-specific values" gives a clear triggering condition, and the mention that set_project_config stores values clarifies the read/write split. It does not cover when to prefer get_project_context or get_project_file over this tool, so it stops short of full when-not guidance.

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