Model Context Protocol (MCP) Server for Territory News —— 为企业销售和客户经理提供实时账户情报、商机信号与战略性开场白。
Territory News MCP（tnews-mcp） 让客户经理（AE）和销售团队摆脱手动操作 Territory News 网页界面的束缚。它通过开放的 Model Context Protocol (MCP) 标准，将领地配置、企业搜索、实时信号预览和 AI 增强的销售上下文开放出来，使得 n8n、OpenClaw、Agentic Hermes、Claude Desktop、Cursor、Gemini 以及自定义 Slack AI Agents 等自主编排器能够在后台持续执行高杠杆的销售工作流。
graph TD
subgraph "MCP Ecosystem"
Cal_MCP["Calendar MCP<br/>(Google / Outlook)"]
T_MCP["Territory News MCP<br/>(Signals, POV, Openers, Tracking)"]
C_MCP["CRM MCP<br/>(Salesforce / HubSpot)"]
E_MCP["Email MCP<br/>(Gmail / Outlook)"]
end
subgraph "Autonomous Orchestration Layer (n8n / OpenClaw / Hermes Agent / Claude)"
LLM["LLM Reasoning & Strategy Engine<br/>(Claude / Gemini / Llama / Hermes)"]
end
Cal_MCP -->|"Upcoming Meetings & Attendees"| LLM
T_MCP -->|"Account News, Executive Moves, Triggers"| LLM
C_MCP -->|"Pipeline Stages, Account Tier, Notes"| LLM
E_MCP -->|"Outreach Drafts & Sequences"| LLM
LLM --> W1["☕ 8:00 AM Morning Intelligence Briefing"]
LLM --> W2["⚡ 5-Minute Pre-Call Battlecard Generator"]
LLM --> W3["🎯 Trigger-Based Stalled Deal Reactivation"]
LLM --> W4["👥 Multi-Threading Consensus Matrix"]
LLM --> W5["🔄 Closed-Loop Feedback & Relevance Tuning"]Related MCP server: DataLayer MCP
与其每天早晨登录 territory.news 手动逐一点击账户、复制开场白，不如将 tnews-mcp 连接到你的多 Agent 运行器（n8n cron 触发器、OpenClaw agent 或 Hermes）：
工作方式：每天早晨 8:00 AM，一个 n8n / OpenClaw cron 任务会唤醒你的销售 Agent。
编排流程：
Agent 调用 CRM MCP 获取活跃的销售管道（Stages 2–4）和顶级 Tier-1 目标账户。
调用 tnews-mcp 上的 territory_get_signals，扫描过去 24 小时内的重大催化剂事件（例如资本支出扩张、CIO 任命、财报超出预期、重组）。
交叉引用你已配置的销售价值主张（territory_get_seller_context），整合出一份包含 3 个要点的 Slack 摘要，并附上可一键发送的预写外联邮件。
对 AE 的价值：你每天看到的是已按优先级排序、可立即发出的外联内容，而不是在 Google Alerts 或浏览器标签页中层层翻找。
工作方式：在任意日历事件前 10 分钟，Agent 自动触发。
编排流程：
Calendar MCP 检测到一场即将开始的会议（例如：“与 Datadog 工程副总裁的 Discovery 通话”）。
Agent 调用 territory_preview_signals(company="Datadog", domain="datadoghq.com") 获取实时新闻与财务催化剂。
Agent 调用 CRM MCP 获取此前通联中的异议与笔记。
Agent 将一页战术级战卡投递到你的收件箱或移动记事本，包含：
战略优先事项：该账户当前正在应对什么。
角色关注焦点：参会角色所关注的核心 KPI 与痛点。
3 个富有冲击力的开场白：以 POV 驱动的开场方式，将其公开新闻与你的产品直接关联。
雷区：竞品部署或应避免提及的敏感话题。
工作方式：用真实的“继续为客户创值”重新激活失联或关闭为输的商机，而不是只“礼仪式地跟进”。
编排流程：
Agent 在 CRM MCP 中查询处于 Stalled / No Contact > 30 Days 且 ARR > $50k 的商机。
Agent 查询 territory_get_signals 获取重大拐点事件（例如新高管任命、业绩超标、并购、监管变化）。
当某个触发条件发生时（例如：“EquipmentShare 以 26% 的营收增速大涨”），Agent 会起草一封具有上下文相关的跟进邮件，将该增长与 CRM 笔记中记录的特定业务诉求关联起来。
工作方式：大型企业交易需要在 6–10 个利益相关方之间形成共识。
编排流程：
当 tnews-mcp 为目标账户识别出单一重大催化剂后，Agent 会自动将事件映射到不同角色：
面向 CFO：成本控制、OPEX 削减、供应商整合等角度。
面向 CISO / 安全：合规自动化、零信任架构、审计风险降低等角度。
面向工程 VP：开发者速度、消除部署成本、DORA 指标提振等角度。
Agent 通过 Email MCP 将定制化的外联草稿放入你的邮件客户端队列中。
工作方式：无需手动配置就能持续提升信号质量。
编排流程：
当你在 Slack 或 Claude 中接受、编辑或拒绝某条外联建议时，Agent 会自动调用 tnews-mcp 上的 territory_submit_feedback。
这会立即将闭环遥测数据传回 Territory News，供其在你的专属领地内持续调整信号评分与相关度模型。
该 MCP 服务器采用高性能混合架构：
一次性浏览器登录：仅启动一次、可见的浏览器窗口，通过 Clerk（工作邮箱 / Google SSO）登录。它会自动捕获会话令牌并保存到 ~/.territory-mcp/session.json。
100% 直接 REST API：后续所有操作均通过 HTTP REST 直接对 Territory News 生态发起请求（延迟 < 150ms，零浏览器开销，完全不受 DOM/UI 变化影响）。
# Clone the repository
git clone https://github.com/junoonx/tnews-mcp.git
cd tnews-mcp
# Install dependencies and build
npm install
npm run build将这段配置添加到你的 claude_desktop_config.json 文件（macOS 路径：~/Library/Application Support/Claude/claude_desktop_config.json；Windows 路径：%APPDATA%\Claude\claude_desktop_config.json）：
{
"mcpServers": {
"territory-news": {
"command": "node",
"args": ["/absolute/path/to/tnews-mcp/dist/index.js"]
}
}
}将其添加到你的 .cursor/mcp.json 或 MCP settings 中：
{
"mcpServers": {
"territory-news": {
"command": "node",
"args": ["/absolute/path/to/tnews-mcp/dist/index.js"]
}
}
}通过 stdio 命令直接传递，或在环境中设置 TERRITORY_SESSION_TOKEN：
TERRITORY_SESSION_TOKEN="your_clerk_session_jwt" node dist/index.js在 Claude/Cursor 中告诉你的 AI 助手：
“登录到 Territory News”
服务器会调用 territory_login_browser，打开浏览器窗口访问 territory.news。使用工作邮箱或 SSO 登录即可。浏览器会自动将会话保存到 ~/.territory-mcp/session.json，并自动关闭。
另一种方式，可以直接在终端执行：
npm run login你可以直接提供会话令牌：
export TERRITORY_SESSION_TOKEN="your_clerk_session_jwt_or_cookie"工具名称 | 参数 | 描述 |
| （无） | 检查认证状态、用户邮箱以及已跟踪账户数量。 |
|
| 打开一个可见的浏览器窗口，用于完成一次性 Clerk 登录。 |
| （无） | 从本地存储中清除已保存的会话凭据。 |
|
| 按模糊名称匹配搜索上市公司/私营公司。 |
|
| 为任何公司预览已通行评审的实时信号与头条。 |
| （无） | 列出你当前监控范围内的全部公司（1–10 个账户）。 |
|
| 在已监控的领地中添加、移除或替换账户。 |
| （无） | 查看你当前的销售人员画像、角色、产品与价值主张。 |
|
| 配置销售上下文，并触发 AI 上下文增强。 |
|
| 获取领地账户的实时信号、战略观点（POV）及交易开场白。 |
| （无） | 触发对全部领地账户的一次实时新闻与交易信号重新扫描。 |
|
| 提交反馈以提升信号相关度并优化 AI 交易开场白。 |
“我下午 2:00 有一个 Datadog 的 Discovery 电话会。请检查我的 Territory News 里 Datadog 的信号，并结合我的销售上下文，给我一页纸的会前战卡，含 3 个高影响力开场问题。”
“在 Territory News 上搜索 Snowflake、Datadog、Stripe 和 HashiCorp，然后将其加入我监控的领地。”
“更新我的 Territory News 销售背景：我是一名企业 AE，销售 AI 可观测性与 FinOps 平台。我的主要使用场景是降低云迁移风险和 Kubernetes 出口流量浪费。我的价值主张是：‘我们帮助企业平台团队避免不可预测的多云出口流量突刺，并在不需要人工 SRE 调参的情况下优化计算资源利用率。’”
“扫描我所有领地账户。展示前三名高杠杆的拐点事件（财报、领导层变动、产品变化），并为每一个事件起草一封可以一键发送的个性化邮件。”
MIT License。
专为高性能销售团队与现代销售工程团队而打造。
Check current authentication status for Territory News, including logged-in user email, user ID, and session file path.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only status check ('Check current authentication status') rather than a mutation, which is the key behavioral disclosure. It names specific fields returned, which is useful context. However, it does not explicitly say whether this performs any network/session mutation or what happens if no session exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence, front-loaded with verb 'check' and resource 'authentication status'. The list of returned values is compact, though it could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple zero-param read tool. The description identifies the checked resource and the three output facetscing. Could add a sentence on when to use it vs. the login and logout siblings, or clarify the meaning of the returned status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters means the schema is trivially complete at 100% coverage. The description adds value by stating what the tool reports (user email, user ID, session file path), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check) + resource (Territory News) and enumerates the exact information returned: user email, user ID, and session file path. This clearly distinguishes it from the sibling auth tools territory_login_browser and territory_logout, which are action tools, not status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose implies it should be used to verify whether a session exists before login or after logout, but the description doesn't explicitly say this. It doesn't name territories_login_browser as the alternative for establishing a session. The context is clear but the exclusions and when-not guidance are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the seller's active sales context (Role, Account Segment, Selling Product, Primary/Secondary Use Cases, Value Proposition, and Enriched AI Context).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not mention authentication requirements, despite sibling tools like territory_auth_status and territory_login_browser suggesting such a dependency. It lists return fields but offers no details on side effects, errors, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, followed by a parenthetical list of included fields. Every word earns its place, and the structure is clean and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter, the description clearly indicates what is returned. However, it omits any mention of prerequisites like login or authentication, which could be critical given the sibling auth and login tools. Minor gap, but otherwise complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to describe beyond what the empty schema shows. The description adds no parameter-related information, which is acceptable given the absence of parameters; a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('seller's active sales context'), and lists specific components (Role, Account Segment, etc.). It is easily distinguished from the sibling setter 'territory_set_seller_context', which performs the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, such as the setter. While the getter nature implies use when you need the current context, there is no direct guidance on when to retrieve versus set, and no mention of prerequisites or common workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time news signals, executive inflection events, and tailored conversation openers for all tracked accounts in your territory (or for specific requested companies).
| Name | Required | Description | Default |
|---|---|---|---|
| company | No | Optional: Filter signals to a specific company in your territory (e.g. 'Snowflake') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure, but it only lists the types of content returned. It does not state whether the tool is read-only, whether it requires existing tracked accounts, whether any scanning is triggered, or how the 'real-time' claim relates to data freshness—leaving important agent-facing behaviors undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that names the returned resource types and the optional scope without any wasted words. It is appropriately sized and communicates the core purpose quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no required params, the description is reasonably complete, but with no output schema it should say more about the shape and granularity of the returned signals and events. It also leaves the relationship to tracked accounts and sibling signal-related tools unstated, which is a noticeable gap for an autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single optional 'company' parameter, so the description adds little beyond restating the filter concept. Schema description coverage is 100%, so the baseline of 3 applies; the phrase 'specific requested companies' reinforces flexibility but does not add semantics about value format or behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies precise resources: real-time news signals, executive inflection events, and tailored conversation openers, scoped to tracked accounts or an optional requested company. It is clearbut does not explicitly differentiate itself from the similar sibling 'territory_preview_signals', so some sibling-routing burden remains on the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives such as 'territory_preview_signals' or 'territory_trigger_scan'. The optional company filter gives scope context, but the description lacks conditions, exclusions, or reference to sibling tools that would help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of currently monitored companies in your territory (supports up to 10 accounts).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It describes a 'get' operation, implying read-only behavior, but does not explicitly state side effects, permissions, or response format. It is adequate for a simple getter but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the tool's purpose and a key constraint. No extraneous information or wordiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, no output schema), the description provides sufficient context: it returns a list of currently monitored companies within a territory, and notes a limit. While it doesn't specify the exact data structure, it gives enough for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description adds no parameter information because there are none, aligning with the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the list of currently monitored companies in the user's territory, with a specific verb 'Get' and resource. It distinguishes from sibling tools like territory_search_companies or territory_update_tracked_companies, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a limitation (supports up to 10 accounts) but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. It is implied as the primary getter, but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launches a visible browser window for one-time Clerk authentication to Territory News. Captures the session cookie and saves it locally.
| Name | Required | Description | Default |
|---|---|---|---|
| timeoutSeconds | No | Max seconds to wait for user to sign in in the browser (default: 180s) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full responsibility for behavioral disclosure. It mentions a 'visible browser window' (user interaction required), 'one-time' authentication, and that it captures and saves a session cookie. It does not specify what happens on failure or whether it overwrites an existing session, but the core behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that conveys the key points without fluff. It covers the action, the target, the mechanism, and the outcome in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an authentication tool with no annotationslogging, the description provides good context: it tells the agent that user interaction is required (visible browser), it captures a session cookie, and it has a timeout. It lacks information about return values or failure modes, but these may be less critical for a this kind of tool. Overall, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, timeoutSeconds, is fully described in the schema with its default value (180s). The description reinforces its purpose by saying 'Max seconds to wait for user to sign in.' There is no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Launches a visible browser window'), the specific resource ('Territory News'), and the outcome ('Captures the session cookie and saves it locally'). It is distinct from sibling tools like territory_auth_status (checking status) and territory_logout (ending session), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It describes the tool as 'one-time authentication' which gives context, but it does not explicitly state when to use this versus alternatives, nor does it mention prerequisites like needing to check auth status first. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear saved session credentials from local storage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It explicitly discloses that the operation removes saved session credentials from local storage, which signals a destructive local side effect. It does not mention whether server-side sessions are invalidated or whether the call is safe when already logged out, but the core side effect is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, front-loaded with the action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter logout tool, the description states the essential effect. It lacks explicit usage context and any mention of return behavior, but the simplicity of the operation keeps the gap minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description cannot add parameter-level meaning. Baseline 4 applies because there is no schema information to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Clear') and resource ('saved session credentials from local storage'), clearly identifying it as the logout counterpart to territory_login_browser and territory_auth_status. It is not a tautology and conveys the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus territory_auth_status or territory_login_browser. An agent must infer that logout is appropriate after a session is no longer needed; there are no explicit conditions, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview recent real-time qualified news signals and headlines for a given company before adding it to your territory.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Optional company domain (e.g. 'snowflake.com', 'anthropic.com') | |
| company | Yes | Company name (e.g. 'Snowflake', 'Anthropic') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'Preview' implies a read-only, non-committal operation, which is useful behavioral context. However, it does not state whether authentication is required, whether any state changes occur, or how real-time data fetching behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a front-loaded verb and resource. It contains no filler, no repetition of schema details, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter preview tool, the schema covers the inputs completely. But with no output schema, the description could say more about what the returned signals/headlines look like and whether a login is a prerequisite; still, the core usage is understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description only says 'given company' and adds no additional semantic detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Preview'), names the resource ('qualified news signals and headlines'), and scopes the use case ('before adding it to your territory'). This timing clearly distinguishes it from post-add signal retrieval like territory_get_signals, even without naming that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before adding it to your territory' tells the agent exactly where this tool fits in the workflow. However, it does not explicitly state when not to use it or mention alternatives such as territory_get_signals for already-tracked companies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for public and private companies on Territory News using fuzzy name matching. Returns name, domain, logo, and ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 8) | |
| query | Yes | Company name or search query (e.g. 'Snowflake', 'Datadog', 'Stripe') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses fuzzy matching and the return fields, which is useful. However, it doesn't mention whether this is a read-only operation, any rate limits, or what happens if no matches are found. For a search tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and includes the key return fields. It's concise with no waste, though it could mention the limit parameter's default behavior, which is already in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with a simple schema and no output schema, the description covers the essentials: what it searches, how (fuzzy), and what it returns. It lacks guidance on edge cases like empty results or pagination, but given the simplicity, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description adds the context of fuzzy matching and return fields, but doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for companies on Territory News with fuzzy name matching and returns specific fields. It distinguishes itself from siblings like territory_get_tracked_companies by focusing on search rather than tracking, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding companies by name, but doesn't explicitly state when to use this vs. other tools like territory_get_tracked_companies or territory_get_seller_context. It provides no exclusions or alternative routing, leaving the agent to infer from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure or update your sales context (Role, Target Segment, Product Sold, Use Cases, Value Created). Automatically calls Territory News AI enrichment engine to tailor deal signals and conversation starters.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Your sales role (e.g. 'AE') | |
| persona | No | Target account segment | |
| valueCreated | Yes | Detailed value proposition / pain relieved (min 60 chars recommended for optimal signal matching) | |
| primaryUseCase | Yes | Primary problem solved (e.g. 'Eliminate cloud compliance drift and accelerate SOC 2 audits') | |
| sellingProduct | Yes | What you sell (e.g. 'Enterprise Cloud Security & Observability platform') | |
| secondaryUseCases | No | Optional secondary use cases |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions that it automatically calls the 'Territory News AI enrichment engine', which is a behavioral trait, but does not disclose side effects (e.g., persistent mutation), permissions required, or error conditions. This is partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and well-structured. The primary action is stated upfront, and the additional detail about the enrichment engine is relevant. No unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should clarify return values and prerequisites, but it does not. It explains what the tool does and its effect, but omits details about what the caller receives (e.g., success confirmation, errors) or any input requirements beyond the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the baseline is 3. The description summarizes the parameters (Role, Target Segment, etc.) but adds no new semantic information beyond what the parameter descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: configuring or updating sales context. It also mentions the specific elements (role, target segment, etc.) and the effect (tailoring deal signals). This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting or updating context, but does not explicitly contrast with the sibling tool 'territory_get_seller_context'. It does not state when to use this over alternatives, leaving some ambiguity for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit feedback on a signal, recommendation, or conversation starter to improve intelligence relevance.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Feedback text (min 10 characters) | |
| feedbackType | Yes | Category of feedback | |
| sectionLabel | No | Optional specific signal title or UI section the feedback refers to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Submit' implies a write operation, but the description does not state whether authentication is required, whether submission is idempotent, what side effects occur, or what response the agent should expect after a successful or failed submission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It names the action, the targets, and the purpose efficiently, and every phrase contributes to the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and its parameter schema is fully self-documenting, but there are no annotations and no output schema. The description omits behavioral context such as authentication requirements and expected response behavior, which an agent would need to handle the call gracefully. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters, including the enum values and the minimum message length. The description adds little parameter-specific meaning beyond clarifying the domain objects the feedback refers to, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('submit feedback') and identifies the exact targets: signals, recommendations, or conversation starters. It also indicates the intended outcome (improve intelligence relevance), which distinguishes it clearly from the sibling tools that search, preview, or manage tracked companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when a user wants to provide feedback on a signal, recommendation, or conversation starter. It does not explicitly name alternatives or state exclusions, but no sibling tool appears to serve a similar feedback purpose, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Triggers a live re-scan of news and signal triggers across all monitored accounts in your territory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It discloses 'triggers a live re-scan' but gives no details about whether the call blocks, what it returns, whether re-scan is asynchronous, or whether repeated triggers have side effects. This is a notable gap for an action that starts background work.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action of 'Triggers a live re-scan' and includes the full scope without wasted words. It is appropriately concise, even it does not fully explore edge cases or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description needed to explain return behavior and side effects, and it doesn't. An agent knows what the tool does, but cannot predict what a successful call returns or whether the operation is asynchronous or potentially destructive, leaving the description incomplete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with zero parameters, so the schema already fully documents the parameter space. The description adds no parameter details because none are needed, matching the 0-parameter baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb–resource pairing: it 'triggers a live re-scan' of news and signal triggers across monitored accounts. This conveys a distinct, non-read-only purpose that differentiates it from related tools like territory_get_signals, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'across all monitored accounts in your territory' tells the agent the operational scope, but nothing explicitly states when this tool should be preferred over related alternatives such as territory_get_signals or territory_preview_signals. The intended usage is implied rather than clearly prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add, remove, or replace monitored companies in your territory (max 10 companies). Automatically resolves domains and tickers.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 'add' to append new companies, 'remove' to delete specific companies, or 'set' to replace the whole list. | |
| companies | Yes | List of company names or domains (e.g. ['Snowflake', 'datadoghq.com', 'Stripe']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does add useful behavioral facts beyond the schema: the 10-company cap and automatic domain/ticker resolution. However, it leaves unstated what happens on exceeding the cap, whether an authenticated territory session is required, and what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight sentence that front-loads the core operation and the most important constraint, then adds a valuable automatic-resolution note. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a complete schema, the description covers the essential operational context: what actions are possible, the size limit, and input handling. It does not mention authentication/session requirements or failure modes, but the tool is simple enough that the remaining gaps are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters fully (100% coverage), so the baseline is 3. The description adds meaningful semantics on top: it clarifies the 10-company limit for the companies array and explains that domain and ticker inputs are automatically resolved, which is not stated in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (add/remove/replace) and a specific resource (monitored companies in your territory), plus a key constraint (max 10). This clearly differentiates it from sibling read/search tools like territory_get_tracked_companies and territory_search_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this tool is for modifying the monitored-company list, while the sibling names indicate read/search alternatives. It doesn't explicitly state 'use X instead when...', so it stops short of a full 5, but the intended usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0territory_auth_statusterritory_get_seller_contextterritory_get_signalsterritory_get_tracked_companiesterritory_login_browserterritory_logoutterritory_preview_signalsterritory_search_companiesterritory_set_seller_contextterritory_submit_feedbackterritory_trigger_scanterritory_update_tracked_companiesScored across 12 tools
Most tools map to distinct resources and actions: auth lifecycle, company search, tracked-company management, seller context, and signal retrieval are clearly separated. There is minor overlap between preview_signals and get_signals since get_signals can also target specific companies, though the intended pre-add versus tracked-account use case helps.
All tools share a consistent territory_ prefix and nearly all follow a verb_noun structure such as search_companies, get_tracked_companies, and set_seller_context. Small deviations like territory_auth_status and territory_login_browser weaken the verb-first pattern slightly, but the overall convention remains predictable.
12 tools is a well-scoped size for a territory intelligence MCP server, with separate groups for auth, company lookup, territory management, seller context, signals, and feedback. Each tool has a distinct responsibility and none feel redundant.
The surface covers the full workflow: authentication, company discovery, signal preview before adding, tracked-company management, seller context configuration, signal retrieval, live rescans, and feedback submission. There are no obvious dead ends or missing lifecycle operations.
Market & Company Intelligence for AI agents: next adoptions, company health, signals, market feeds.
AI-native B2B sales research, ranking, and CRM enrichment.
Sales research and prep tools for B2B reps. Prospect briefs, angles, citations.
DACH B2B opportunity intelligence for AI agents with FIT/NEED/NOW scoring, timing signals, sales-agent workflows and CRM delivery to HubSpot and Pipedrive.
