Provides competitive battlecard templates for positioning against Salesforce as a legacy incumbent in RFP responses.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Sales-Engineering/RFP-Response MCP Provide template for encryption at rest in SOC2 questionnaire"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Drop-in templates for security questionnaires (SOC2, ISO27001, HIPAA, GDPR, NIST CSF, PCI-DSS), RFP responses, and competitive battlecards. For AI sales agents and human sales engineers.
Built from 10+ years of B2B enterprise sales experience.
Disclaimer. Outputs are structured starting templates based on publicly-documented security frameworks. They are NOT (a) a substitute for the actual content of your security program, (b) legal advice, (c) a certified audit attestation, (d) a guarantee of compliance. Replace bracketed placeholders with your specific facts. Have qualified security and legal counsel review before submitting any actual RFP or questionnaire response.
Mid-market B2B SaaS sales engineering teams burn 100-300 hours per quarter answering the same security and RFP questions. Loopio and Responsive sell point solutions for this at $30-100K/year per company.
AI agents can do this work better — but they need a structured library of starting templates to draft from. This MCP provides that library.
Use case: an AI agent receives a 200-question security questionnaire. It calls this MCP for each question, gets a starting template, fills in customer-specific facts, and submits a draft for human review.
Related MCP server: SMB Sales Intelligence MCP
Tool | What it returns |
| SOC2 / ISO27001 / HIPAA / GDPR / NIST CSF / PCI-DSS attestation templates with placeholders |
| 10 common security questionnaire questions with template responses (encryption, access control, vulnerability mgmt, IR, retention, sub-processors, residency, SLA, AI usage) |
| 7 common RFP sections (overview, architecture, integrations, pricing, SLA, competitive displacement, references) |
| 3 competitive scenarios (vs legacy incumbent, vs modern competitor, vs DIY internal build) |
| Free-text search across all questionnaire topics |
| Discovery — all available frameworks, topics, sections, scenarios |
| Complete library for fine-tuning or full agent context |
// 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 Pay-Per-Event: $0.05 per tool call
First 10 calls free per actor
SOC 2 Type II · ISO/IEC 27001:2022 · HIPAA · GDPR · NIST CSF 2.0 · PCI DSS 4.0
Encryption at rest · Encryption in transit · Access control / least privilege · Vulnerability management · Incident response · Data retention · Sub-processors · Data residency · Uptime SLA · AI data usage policy
Company overview · Technical architecture · Integrations · Pricing · SLA & support · Competitive displacement · References
vs Legacy Incumbent · vs Modern Competitor · vs DIY Internal Build
v1.1: Add SOC 1, FedRAMP, StateRAMP, IRAP (Australia), CSA STAR, BSI C5 (Germany)
v1.2: Vertical-specific Q&A (FinTech: PCI deep-dive, Healthcare: HIPAA + HITRUST, EdTech: FERPA/COPPA)
v1.3: Bring-your-own-evidence adapter — pull current attestations from Vanta/Drata via API
v2.0: Smart RFP-response — given a full RFP doc, pre-draft the entire response
Elisabeth Hitz — 10+ years of B2B enterprise sales experience. Worked sales engineering and RFP responses across SaaS verticals.
License: 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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Sales research and prep tools for B2B reps. Prospect briefs, angles, citations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/closermethod/sales-engineering-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
