Skip to main content
Glama

Get project

get_project
Read-only

Returns what an agent needs to know about a site before content or SEO work, in sections. Pass sections to pick them; without it, the tool returns profile, settings and integrations. The result has one key for each section. profile: the site’s name and domain, its brand profile (metadata such as the main keyword, market and country, the audience, Brand Voice, Content Guardrails, Offer Positioning, competitors and sitemap counts), whether the owner has completed the brand profile review, the setup checklist and the stored Domain Rating. Content generation uses the brand profile only after the review is complete; the owner completes it in Keytomic at profileUrl, never through this server. legacyCustomInstructions is a legacy free-text field kept for older generation paths: read it, but put new rules in Content Guardrails, Brand Voice or Offer Positioning with update_brand_profile. A site whose brand profile is not generated yet has brandProfile null; brandProfileGenerationFailed true means the last generation failed; the owner cannot start it again and should contact Keytomic support. sitemapInventory.collectionPending true means the sitemap counts are not final yet. settings: Article Settings (length, tone, voice instructions, internal links, inline images, YouTube and the author override), indexing settings (the URL prefix of the site’s posts), the automatic blog schedule (days, whether drafts publish automatically and to how many destinations, and whether article snapshots are on) and the author profiles with the default author. The automatic blog schedule is read only here; the owner changes it in Keytomic. Edit the rest with update_project_settings, save_author_profile and delete_author_profile. usage: for this site, each Usage Limit with a cap: what was used in its window (day, week, month or all time), the limit and what is left. A metered action with no cap is not listed. Read it before work that spends credits. integrations: Google Search Console, Google Analytics, Bing Webmaster and each Shopify store. Each entry has a name (the property, site or store; null when not connected) and a status: connected, needs_attention (the owner must reconnect or fix it) or not_connected. Entries that are not connected have a connectUrl, where the owner connects or fixes the integration in Keytomic. destinations: the CMS, webhook and API destinations the site can publish articles to (Shopify stores too), its own and the workspace-wide ones. Each has a destinationId for publish_draft, the provider, a name, a status (connected, or needs_attention with a fixUrl), draftMode (kept_as_draft: a draft publish stays a draft on the destination; receiver_decides: Keytomic sends the mode and the receiver decides; not_supported: the destination has no draft mode), autoPublish (whether automatic publishing sends new articles to it) and workspaceWide. A site without a destination has an empty list with a connectUrl, where the owner connects one in Keytomic. property: the site’s connected Search Console property (propertyId, propertyUrl) and the connected Google account’s permission level on it (permissionLevel, null when Google gives none). It is read live from Google. keywordSearches: how many calendar keyword searches the site has left this month, how many were made on it today, and whether a search can run now (canSearch, with blockedBy when it cannot). Keytomic counts keyword searches per site: the searches of all members of the site count together. profile, settings, usage and integrations need workspace:read; destinations and keywordSearches need content:read; property needs gsc:read. A section this connection may not read has error scope_missing, and a section that fails has an error code and a message: a usage refusal with its own code; a Search Console error in property, with its own code, retryable, and connectUrl or retryAfterSeconds when they apply; or internal_error. A scope_missing message names the sections this connection can read. The other sections still return; when every section has an error, the call is a tool error: the section’s error when one section was requested, otherwise sections_failed with each section’s error under its name.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>"
    },
    "name": "get_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
sectionsNoSections to return. Without it: profile, settings and integrations. usage, destinations, property and keywordSearches are returned only on request.
projectIdYesSite to act on, from list_sites.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.5/5.0
Behavior4/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 is consistent with that while adding substantial depth: per-section scope requirements (workspace:read, content:read, gsc:read), partial-failure semantics, scope_missing/internal_error codes, and the sections_failed tool-error condition. It explains the null/failure states (brandProfile null, brandProfileGenerationFailed, collectionPending, needs_attention with fixUrl) that no annotation conveys. It stops short of describing payload size or latency for a large multi-section response, which keeps it from a 5.

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

Conciseness3/5

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

The core routing information is front-loaded and the per-section organization mirrors the enum, but the body is an extremely dense wall of text with very long compound sentences packing permissions, error codes and null semantics into single clauses. Much of that content earns its place, yet it could be shortened substantially without losing agent-relevant meaning.

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?

There is no output schema, so the description carries the full burden of explaining return values, and it does so section by section, including the partial-result and total-failure shapes. For a tool with seven conditional sections and three distinct scope requirements, nothing an agent needs to interpret a result is missing.

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 the baseline would be 3, but the description goes beyond the schema by explaining what each enum value actually yields (profile, settings, usage, integrations, destinations, property, keywordSearches) and restates the default-section behavior. projectId itself is only echoed from the schema, so the gain is on one parameter of two.

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 opening sentence names the verb and the resource concretely ('Returns what an agent needs to know about a site before content or SEO work, in sections') and the section enumeration pins down exactly what is returned. It also routes mutation paths to named siblings (update_project_settings, update_brand_profile, save_author_profile, delete_author_profile), so an agent can tell this read tool apart from the write tools without opening a 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?

It states the usage trigger ('before content or SEO work', 'read it before work that spends credits') and the selection rule for sections, including the exact default set when sections is omitted. It also names explicit alternatives for every write path and says the automatic blog schedule is read-only here and changed in Keytomic, which is a clear when-not-to-use signal.

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.

Resources