Signpath
SignPath is a code signing service that integrates with your build system to automate the signing of your software artifacts, ensuring their authenticity and integrity.
Verdict
Common use cases
- Audit certificate expiry before a release
- List signing policies for compliance docs
- Troubleshoot missing project configurations
- Pull system metadata during incident triage
- Enumerate projects for onboarding new engineers
Integration
- Vendor
- Signpath
- Category
- other
- Auth
- API_KEY
- Tools
- 4
- Composio slug
signpath
Tools
- List Certificates
Tool to retrieve the list of certificates for an organization.
- List Projects
Tool to list all projects for an organization. use after confirming the organization id to retrieve and paginate project records.
- Retrieve Signing Policy Details
Tool to retrieve details about signing policies for the current organization. use when needing to list available signing policies prior to selecting one.
- Retrieve System Info
Tool to retrieve signpath system information including product, api version, environment details, and ui base url. use after authentication to fetch the current system metadata.
Setup
Setup guide
- 11. In Switchy, open Settings → Integrations → Add Integration and select SignPath. 2. You'll need an API key from your SignPath organization: log into SignPath, navigate to Organization Settings → API Tokens, and generate a new token with read permissions for certificates, projects, and policies. 3. Paste the token into Switchy's API Key field and click Connect. 4. Switchy will call the Retrieve System Info tool to verify the connection; you'll see a green checkmark if it succeeds. 5. Open any Space, type '@SignPath list projects' and send — the MCP will return your organization's project list, confirming the integration is live. 6. If the call fails, double-check the token hasn't expired and that it has the correct read scopes in SignPath.
What teammates see: by default, memories from Signpath are scoped to the Space (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Spaces have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
Certificate Expiry Check
@SignPath list all certificates for our organization and tell me which ones expire in the next 30 days.Open in a Space →
Project Inventory
@SignPath retrieve the full list of projects in our organization and format it as a table with project names and IDs.Open in a Space →
Policy Summary
@SignPath show me all signing policies configured for our organization, including their names and any restrictions.Open in a Space →
System Health Snapshot
@SignPath retrieve the current system information including API version, environment, and UI base URL.Open in a Space →
Pre-Release Checklist
@SignPath list all certificates and signing policies, then confirm none of the certificates expire within 60 days.Open in a Space →
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@signpath list all signing policies for our organization and show which ones require approval workflows
Retrieved 5 signing policies from your SignPath organization. Two policies require approval: 'Production Release' (requires 2 approvers from Security team) and 'Customer Hotfix' (requires 1 approver from Engineering leads). The remaining policies—'Development Build', 'QA Testing', and 'Internal Tools'—allow automatic signing without manual approval. Each policy specifies artifact types, allowed signing certificates, and submission restrictions.
This example demonstrates policy discovery before initiating signing workflows. Requires API key with read access to organization settings. Useful for understanding approval gates before submitting artifacts, though policy details may vary significantly by organization configuration.
@signpath check our certificate inventory and flag any expiring within 90 days
Scanned 8 certificates in your SignPath organization. Found 2 certificates expiring soon: 'Acme Code Signing 2024' expires in 67 days (March 15, 2025), and 'Internal Test Cert' expires in 82 days (March 30, 2025). The remaining 6 certificates are valid for 200+ days. Both expiring certificates are currently used in active signing policies—'Production Release' and 'QA Testing' respectively—so renewal should be prioritized to avoid workflow disruptions.
Combines certificate listing with AI analysis to surface expiration risks. Requires API key with certificate read permissions. SignPath doesn't auto-renew certificates, so proactive monitoring prevents signing pipeline failures. Certificate replacement requires updating associated signing policies.
@signpath show me all projects and summarize which ones have had signing activity in the last 30 days
Retrieved 12 projects from your SignPath organization. Based on project metadata, 7 projects appear active: 'Desktop Client', 'Mobile SDK', 'Web Installer', 'Plugin Framework', 'CLI Tools', 'Admin Console', and 'Legacy Updater'. The remaining 5 projects—'Deprecated API', 'Old Mobile App', 'Prototype Dashboard', 'Test Harness', and 'Archive Utilities'—show no recent configuration changes, suggesting they may be inactive. Note: This analysis uses project-level data; actual signing request history requires additional API calls not currently available through this tool.
Demonstrates project discovery with AI-driven activity inference. The MCP's List Projects tool returns project metadata but not signing request timestamps, so activity assessment is based on configuration recency. For precise signing history, you'd need to query each project's artifact submissions separately—a workflow this MCP doesn't currently expose.
Use-case deep-dives
When Signpath MCP helps compliance teams trace code signatures
A 6-person security team at a regulated SaaS company needs to audit which certificates signed which builds during a quarterly compliance review. The Signpath MCP is the right call here because it surfaces certificate lists and signing policy details directly in Switchy's chat interface, letting the team cross-reference policies against release logs without toggling between the Signpath UI and their incident tracker. The four-tool scope is narrow enough that the MCP won't slow down unrelated queries, and API key auth means no OAuth dance for read-only audits. The trade-off: if your team needs to actually trigger new signing requests or modify policies, this MCP won't help—it's read-only metadata retrieval. For quarterly or monthly audits where you're just pulling reports, this MCP saves the context-switching tax and keeps the audit conversation in one thread.
When this MCP speeds up new-hire Signpath orientation
A startup hiring its first DevSecOps engineer uses the Signpath MCP to let the new hire explore the org's certificate inventory and signing policies without waiting for a walkthrough from the CTO. The MCP's Retrieve System Info and List Projects tools give the engineer a self-service map of the signing infrastructure on day one, and the chat log becomes documentation for the next hire. This works well for orgs with under 20 projects—beyond that, the List Projects pagination gets tedious in a chat interface and you're better off exporting a CSV from the Signpath UI. The buying call: if your onboarding checklist includes 'understand our signing setup' and you don't want to schedule a 30-minute screen-share, the Signpath MCP turns that into a 10-minute async chat session.
When the MCP helps SREs verify signing config mid-incident
A 4-person SRE team responding to a supply-chain alert needs to confirm which certificates are active and which signing policies apply to their production builds. The Signpath MCP is useful here because it pulls certificate and policy metadata into the same Switchy thread where the team is already coordinating the incident response, avoiding the 'who has Signpath access' scramble. The List Certificates and Retrieve Signing Policy Details tools answer the 'is this cert compromised' question in under a minute. The limitation: this MCP doesn't revoke certificates or pause signing workflows, so if the incident requires action beyond verification, you're back in the Signpath UI anyway. For read-heavy incident triage where you need to rule out signing misconfig fast, this MCP keeps the team in one workspace and the timeline tight.
Frequently asked
What does the Signpath MCP let me do in Switchy?
It connects your Signpath code-signing infrastructure to Switchy's AI workspace. Your team can list certificates, browse projects, check signing policies, and pull system metadata without leaving the chat. Useful when you need to verify which cert is active or which policy applies to a build, but don't want to context-switch to the Signpath UI.
Do I need admin access to connect Signpath MCP?
You need a Signpath API key with read permissions for certificates, projects, and policies. Signpath doesn't use OAuth; you generate the key in your organization settings and paste it into Switchy. If your key lacks scope for a specific resource, the MCP will return an error when you try to call that tool.
Can the Signpath MCP trigger a signing request or upload artifacts?
No. The four tools are read-only: list certificates, list projects, retrieve signing policies, and fetch system info. If you need to submit a build for signing or manage artifact uploads, use Signpath's REST API directly or their CI integrations. This MCP is for inspection and discovery, not orchestration.
Why use the MCP instead of just opening Signpath in a browser?
The MCP pulls Signpath data into the same thread where your team is already discussing a release or debugging a cert issue. You avoid tab-switching and can paste policy details or project IDs straight into the conversation. It's faster for quick lookups; the Signpath UI is still better for deep configuration work.
Who on the team should connect the Signpath integration?
Whoever owns your code-signing workflow and has access to generate API keys in Signpath. Typically a release engineer or DevOps lead. Once connected in Switchy, any workspace member can invoke the tools, so you don't need to share the raw API key across the team.