Skip to main content
Glama

Refresh company profile

campaignstack_refresh_company_profile

Use this when the user asks to read the workspace's own website into its company profile again, the facts every message is grounded on. It reads up to six pages of the workspace website and writes what they say into the profile fields nobody typed by hand; fields a person or an agent wrote stay as written. It returns the fields updated, the fields kept, or why it did not run. When what the site says would not fit the 2,500 character company context, nothing is written and the error names the fields that did not fit. Instead use campaignstack_edit_workspace to set profile fields directly, or campaignstack_analyze_company_website to read another site without storing anything. Charges website_intel credits per call; campaignstack_estimate_cost gives the number before you commit. Charged once per workspace and domain per day, and only when the profile is written. Refresh observes current first-party or public facts again. Say what was refreshed and how fresh the result is; do not imply it found contact data unless this tool says so. This can spend credits, paid provider quota, or model-backed work. Tell the user the cost or budget meaning first when the tool reports one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "campaignstack_refresh_company_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
workspaceIdNoWorkspace ID. Omit it when this connection reaches one workspace: a workspace key (cs_) is bound to its own, and a user key (csu_) or connected app whose person belongs to exactly one workspace defaults to that one. Required only when the person belongs to several; the error then lists them, and campaignstack_whoami reports them too.

Output Schema

NameRequiredDescriptionDefault
okNo
resultsNo
warningsNo
workspaceIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Goes well beyond the annotations: it discloses that only machine-derived fields are overwritten while human/agent-authored fields are preserved, the 2,500-character limit that aborts the write and names failing fields, per-call website_intel credit charges, and once-per-workspace-and-domain-per-day billing that only fires on an actual write. This is exactly the kind of mutation, cost, and failure-mode context annotations cannot carry. It stops short of describing concurrency or partial-write behavior, so not 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?

Purpose and alternatives are front-loaded, which is good, but the text runs long and the closing lines ('This can spend credits, paid provider quota, or model-backed work. Tell the user the cost or budget meaning first...') read as generic boilerplate repeated across the toolset. The output-narration instructions ('Say what was refreshed and how fresh the result is') are useful but could be tightened into one clause.

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?

For a single-parameter, non-destructive but credit-charging write tool, the definition covers trigger, alternatives, preservation semantics, failure mode, and cost model. An output schema exists, yet the description still orients the agent on what comes back, so nothing needed to call it correctly is missing.

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?

Only one optional parameter and the schema already documents workspaceId at full coverage, including the cs_/csu_ key semantics and the multi-workspace error case. The description adds nothing about the parameter, which is acceptable here but is the baseline, not a value-add.

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: it reads the workspace's own website into the company profile, described concretely as 'the facts every message is grounded on'. It also names the two siblings it is not (campaignstack_edit_workspace, campaignstack_analyze_company_website), so the agent can discriminate 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?

Opens with an explicit trigger ('Use this when the user asks to read the workspace's own website into its company profile again') and supplies alternatives with their selecting conditions: edit_workspace to set fields directly, analyze_company_website to read another site without storing. When-not guidance is implicit but the alternatives cover the decision space.

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