用于安全问卷（SOC2、ISO27001、HIPAA、GDPR、NIST CSF、PCI-DSS）、RFP 响应和竞争分析卡的即插即用模板。适用于 AI 销售代理和人类销售工程师。
基于 10 多年的 B2B 企业销售经验构建。
免责声明。 输出内容是基于公开记录的安全框架构建的起始模板。它们不是 (a) 您实际安全计划内容的替代品，(b) 法律建议，(c) 认证审计证明，(d) 合规性保证。请用您的具体事实替换括号中的占位符。在提交任何实际的 RFP 或问卷回复之前，请让合格的安全和法律顾问进行审查。
中型 B2B SaaS 销售工程团队每季度花费 100-300 小时回答相同的安全和 RFP 问题。Loopio 和 Responsive 为此提供单点解决方案，每家公司每年收费 3-10 万美元。
AI 代理可以更好地完成这项工作——但它们需要一个结构化的模板库来起草内容。此 MCP 提供了该库。
用例： AI 代理收到一份 200 个问题的安全问卷。它为每个问题调用此 MCP，获取起始模板，填入客户特定的事实，并提交草稿供人工审核。
Related MCP server: SMB Sales Intelligence MCP
工具 | 返回内容 |
| 带有占位符的 SOC2 / ISO27001 / HIPAA / GDPR / NIST CSF / PCI-DSS 认证模板 |
| 10 个常见的安全问卷问题及模板回复（加密、访问控制、漏洞管理、事件响应、保留策略、子处理商、数据驻留、SLA、AI 使用） |
| 7 个常见的 RFP 部分（概述、架构、集成、定价、SLA、竞争替代、参考资料） |
| 3 种竞争场景（对比传统老牌厂商、对比现代竞争对手、对比内部自建） |
| 跨所有问卷主题的全文搜索 |
| 发现 — 所有可用的框架、主题、部分、场景 |
| 用于微调或完整代理上下文的完整库 |
// Customer questionnaire asks: "What encryption do you use for data at rest?"
mcp.call("get_questionnaire_response", { topic: "encryption_at_rest" });
// Returns starting template with placeholders for KMS provider, rotation cadence
// RFP needs a competitive section vs Salesforce
mcp.call("get_competitive_battlecard", { scenario: "vs_legacy_incumbent" });
// Returns differentiation pattern, common objections + responses, pricing playApify 按事件付费：每次工具调用 $0.05
每个执行器前 10 次调用免费
SOC 2 Type II · ISO/IEC 27001:2022 · HIPAA · GDPR · NIST CSF 2.0 · PCI DSS 4.0
静态加密 · 传输中加密 · 访问控制 / 最小权限原则 · 漏洞管理 · 事件响应 · 数据保留 · 子处理商 · 数据驻留 · 正常运行时间 SLA · AI 数据使用政策
公司概述 · 技术架构 · 集成 · 定价 · SLA 与支持 · 竞争替代 · 参考资料
对比传统老牌厂商 · 对比现代竞争对手 · 对比内部自建
v1.1：添加 SOC 1、FedRAMP、StateRAMP、IRAP（澳大利亚）、CSA STAR、BSI C5（德国）
v1.2：垂直行业特定的问答（金融科技：PCI 深度解析，医疗保健：HIPAA + HITRUST，教育科技：FERPA/COPPA）
v1.3：自带证据适配器 — 通过 API 从 Vanta/Drata 拉取当前认证
v2.0：智能 RFP 响应 — 给定完整的 RFP 文档，预先起草整个回复
Elisabeth Hitz — 拥有 10 多年 B2B 企业销售经验。曾在多个 SaaS 垂直领域从事销售工程和 RFP 响应工作。
许可证：MIT
Returns a battlecard scaffold for a competitive sales scenario. Scenarios: vs_legacy_incumbent, vs_modern_competitor, vs_diy_internal.
| Name | Required | Description | Default |
|---|---|---|---|
| scenario | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It only states the return type ('scaffold') without specifying the format, content, side effects, or auth requirements. The agent has minimal insight into what a 'scaffold' entails.
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?
Extremely concise: one sentence plus a list of scenarios. The purpose is front-loaded, and there is no unnecessary information. Every part 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?
Given the simplicity (one enum param, no output schema), the description is too sparse. It fails to explain the return structure, typical usage context, or any limitations. The agent would be uncertain about the nature of a 'battlecard scaffold'.
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 coverage is 0% (no parameter descriptions), and the parameter 'scenario' has an enum with three values that are also listed in the description. The description adds context ('competitive sales scenario') but does not clarify what each scenario means beyond its identifier.
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 returns a 'battlecard scaffold' for competitive sales scenarios, and lists the three allowed scenario values. The verb 'returns' and specific resource distinguish it from sibling tools like questionnaire or RFP templates.
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 when to use the tool—when a battlecard for one of the listed competitive scenarios is needed—but does not explicitly state when not to use it or mention alternative tools. No usage exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the complete library — all frameworks, questionnaire Q&A, RFP templates, battlecards, and metadata. Useful for fine-tuning or full agent context loading.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present; description only lists contents. Does not disclose potential large payload, performance impact, or access requirements, leaving agent uninformed about behavioral traits.
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?
Two sentences efficiently convey purpose and usage. No redundant information, well front-loaded.
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?
Lists returned content but omits important operational details like potential size, pagination, or rate limits. Lacks output schema; description partially compensates.
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?
No parameters exist (schema coverage 100%). Description clarifies what data is returned, adding value 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?
Explicitly states it returns the complete library listing specific content types (frameworks, questionnaire Q&A, RFP templates, battlecards, metadata). Clearly distinguishes from sibling tools that retrieve individual items.
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?
Provides use cases: fine-tuning or full agent context loading. Lacks explicit when-not-to-use or alternatives, but context is sufficient for typical selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a starting-template response for a common security questionnaire question. Topics: encryption_at_rest, encryption_in_transit, access_control_least_privilege, vulnerability_management, incident_response, data_retention, subprocessors, data_residency, uptime_sla, ai_data_usage.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It states the tool 'returns a starting-template response' but does not clarify if the operation is read-only, requires authentication, or any side effects. The nature of the response (e.g., format, size) is also not described, leaving gaps for a tool with no annotation coverage.
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 followed by a list of topics, efficiently conveying purpose without extraneous information. The list is slightly redundant given the schema, but it aids quick scanning. It could be more concise by omitting the list, but it remains front-loaded and clear.
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 tool with one required parameter and no output schema, the description is fairly complete. It defines the tool's function and the parameter's valid values. However, it lacks elaboration on what a 'starting-template response' entails (e.g., format, length) and doesn't mention that the response is for a questionnaire (though implied by the tool name). Overall adequate but not rich.
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 fully covers the parameter with an enum, achieving 100% coverage. The description adds marginal value by listing the enum values and labeling them as security questionnaire topics. However, it does not explain the meaning or usage of each topic beyond the enum names, so the added semantic value is limited.
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 explicitly states the tool returns a starting-template response for a common security questionnaire question, with a specific verb ('Returns') and resource ('starting-template response'). It clearly distinguishes from siblings like get_rfp_response_template (RFP) and get_competitive_battlecard (competitive analysis) by focusing on security questionnaire responses.
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 when to use (when a template for listed topics is needed) but provides no explicit guidance on when not to use or alternatives. Siblings like get_full_pack or list_all_topics could be relevant but are not mentioned, leaving the agent to infer usage from the topic list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a starting-template response for a common RFP section. Sections: company_overview, technical_architecture, integrations, pricing, sla_support, competitive_displacement, references.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose return format, side effects (e.g., read-only nature), or any behavioral traits beyond stating it returns a template. The agent gets minimal behavioral insight.
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 extremely concise with two sentences. The purpose is front-loaded in the first sentence, and the second sentence lists the enum values without any filler.
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 tool with one parameter and no output schema, the description adequately covers the purpose and available inputs. It doesn't describe the return format, but the notion of a 'starting-template response' implies a standard structure.
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 defines the 'section' parameter with enum values, but the description adds context by explaining these are 'common RFP sections'. However, it does not describe any additional meaning or constraints beyond re-listing the enum values.
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 ('returns a starting-template response') and the specific resource ('common RFP section'). It lists all available sections, making the tool's purpose unambiguous and easily distinguishable from siblings like 'get_competitive_battlecard'.
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 lists the sections but provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context for use, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a structured starting template for a security framework attestation. Frameworks: soc2_type_2, iso_27001, hipaa, gdpr, nist_csf, pci_dss. Replace bracketed placeholders with your specific facts.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses that the tool returns a template with placeholders, implying a read-only operation. However, it does not mention any side effects, error handling, or whether the template is generated dynamically or static.
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 three sentences, each serving a purpose: purpose, framework list, and usage instruction. No superfluous words, but the list is redundant with 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 simple tool with one parameter and no output schema, the description adequately explains the output format (structured starting template) and how to use it (replace placeholders). It could mention if the template varies by framework beyond the schema enum.
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 has 0% description coverage, so the description must compensate. It lists the enum values again (as frameworks) which adds no new meaning, and the placeholder instruction pertains to the output, not the parameter. The parameter's role is clear but not enriched.
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 explicitly states it returns a structured starting template for a security framework attestation, listing specific frameworks. This distinguishes it from sibling tools like get_questionnaire_response which handle different content.
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 only instructs to replace placeholders with specific facts, but does not provide guidance on when to prefer this tool over alternatives (e.g., get_full_pack or search_questionnaire). No scenarios or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full list of available frameworks, questionnaire topics, RFP sections, and battlecards.
| 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 full burden for behavioral disclosure. It only states the tool returns a list, with no mention of side effects, permissions, rate limits, or whether the operation is read-only. The agent lacks critical behavioral context.
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 efficiently conveys the tool's action and result. It is front-loaded with the key verb 'Returns' and immediately specifies the resources. No redundant words; 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?
Given the tool has no parameters, no output schema, and no annotations, the description is the sole source of information. It adequately explains the high-level purpose but lacks details such as return format, pagination, authentication requirements, or potential performance implications. For a simple list retrieval, it is minimally acceptable 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?
The input schema has zero parameters, so schema coverage is trivially 100%. Baseline for 0 parameters is 4. The description adds value by explaining what the tool returns, which is essential since the schema provides no structure. However, it could be more precise about the exact fields or types returned.
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 returns a full list of frameworks, questionnaire topics, RFP sections, and battlecards. The verb 'Returns' and the specific resources make the purpose clear. However, the tool name 'list_all_topics' is narrower than the description, which could cause slight confusion. Still, it effectively distinguishes from siblings that retrieve single items.
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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where other sibling tools might be more appropriate. The agent receives no context for decision-making beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across all questionnaire topics by free-text. Useful when an AI agent has a question phrasing that doesn't directly map to a topic key.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text security/compliance question |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits such as search scope limitations, pagination, or performance characteristics, beyond stating it searches across all topics.
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, front-loading the core action and purpose with no wasted words.
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 description covers purpose and a usage scenario, but lacks details about output format or any limitations. Given no output schema, more context about return values would improve completeness.
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 coverage is 100% with a clear description for the 'query' parameter. The tool description adds context about free-text search across all topics, but does not provide additional semantics like query syntax or length limits.
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 across all questionnaire topics by free-text, using specific verb and resource. It distinguishes itself from siblings like get_questionnaire_response and list_all_topics which serve 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 explicitly mentions a use case: when a question phrasing doesn't directly map to a topic key. This implies when not to use it, but does not name alternative tools directly.
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.0get_competitive_battlecardget_full_packget_questionnaire_responseget_rfp_response_templateget_security_attestationlist_all_topicssearch_questionnaireScored across 7 tools
Each tool serves a distinct purpose: battlecards, full pack, questionnaire, RFP, security attestation, listing, and searching. The descriptions clearly differentiate them, minimizing confusion.
Most tools use a 'get_' prefix pattern, with two exceptions ('list_all_topics', 'search_questionnaire'). This is mostly consistent and readable, with minor deviation.
Seven tools are well-scoped for the server's purpose of providing RFP and security questionnaire templates and knowledge. No tools feel extraneous or missing.
The tool set covers all evident needs: listing available topics, searching, retrieving specific templates (battlecard, questionnaire, RFP, security attestation), and a bulk retrieval option. No obvious gaps in the provided domain.
Draft cited RFP and security questionnaire answers from your knowledge base, with human review
AI-powered RFP response management. Search Q&A libraries, draft responses, and upload documents.
Shared, permission-aware company context for AI agents, with provenance, approvals and audit.
Connect your AI assistant to governed tender and RFP dossiers: sources, versions, decisions.
