Skip to main content
This document specifies the exact MCP implementation details for Poke as an MCP client. Use this as a technical reference when building integrations.

Protocol Versions

SDK Version

Poke uses MCP TypeScript SDK v1.17.3

Supported Protocol Versions

  • 2025-06-18 (latest) - Primary support
  • 2024-11-05 - Backward compatibility fallback

Default Negotiated Version

2025-03-26

Version Negotiation

During the initialization handshake, Poke and your server negotiate the highest mutually supported protocol version. Negotiation flow:
  1. Client sends initialize request with supported versions
  2. Server responds with its supported versions
  3. Highest common version is selected
  4. All subsequent communication uses negotiated version
If no common version exists, the connection fails.

Capabilities Matrix

Poke declares these capabilities during initialization:
CapabilitySupportImplementation Details
tools✅ FullSupports tools/list and tools/call
prompts❌ NoneNot called, safe to expose
resources❌ NoneNot called, safe to expose
roots❌ NoneNot implemented
elicitation❌ NoneNot implemented
sampling❌ NoneNot implemented

Tools Capability

Poke implements the complete Tools capability: Supported Operations:
  • tools/list - Discovery of available tools
  • tools/call - Execution of tools with parameters
Behavior:
  • Tools are discovered once during initial connection
  • Tool schemas are cached for the session lifetime
  • No automatic re-discovery (users must disconnect/reconnect for updates)
  • See Tool Lifecycle for caching details

Transport Layer

Supported Transports

Poke implements two MCP transport protocols:

1. Streamable HTTP (Primary)

Specification: MCP Streamable HTTP Behavior:
  • Attempted first on all new connections
  • Uses HTTP POST to server endpoint
  • Supports streaming responses
  • Recommended for all new integrations
Request Format:
POST /mcp HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "method": "tools/list",
  "id": 1
}

2. SSE (Server-Sent Events)

Specification: MCP SSE Behavior:
  • Automatic fallback if HTTP fails for non-authentication reasons
  • Used for backward compatibility
  • One-way server-to-client streaming

Transport Selection

Poke uses this algorithm to select transport:
Key Behaviors:
  • Transport is detected once during initial connection
  • Selected transport is stored and reused for all future calls
  • No per-call transport fallback after initial detection
  • Authentication failures prevent fallback to SSE
  • Connection failures clear stored transport preference

Unsupported Transports

stdio - Not supported. For local development, use: Deploy your server to HTTPS for Poke integration.

Server Metadata

During initialization, Poke extracts these metadata fields from your server’s response:

Required Fields

FieldTypeDescriptionUsage in Poke
namestringServer identifierShown to agents during tool execution
versionstringSemantic versionLogged for debugging, not shown to users

Optional Fields

FieldTypeDescriptionUsage in Poke
titlestringHuman-readable nameDisplayed in integration settings UI
instructionsstringAgent guidanceCritical: Passed to execution agent for tool usage decisions

Instructions Field

The instructions field is the most important metadata for integration quality. Purpose:
  • Guides Poke’s execution agent on when and how to use your tools
  • Acts as the “system prompt” for your integration
  • Dramatically impacts agent performance
Example:
{
  "name": "github-integration",
  "version": "1.0.0",
  "title": "GitHub Integration",
  "instructions": "Use this integration to manage GitHub repositories, issues, and pull requests. Always search for repositories before creating issues. When creating PRs, fetch the latest branch status first to avoid conflicts. Use list_issues to check existing issues before creating duplicates."
}
See Server Instructions for comprehensive guidance.

Connection Lifecycle

Initialization Sequence

Tool Discovery

Poke calls tools/list immediately after initialization: Request:
{
  "jsonrpc": "2.0",
  "method": "tools/list",
  "id": 2
}
Expected Response:
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "search_repositories",
        "description": "Search GitHub repositories by query string",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": {
              "type": "string",
              "description": "Search query"
            }
          },
          "required": ["query"]
        }
      }
    ]
  }
}
Caching Behavior:
  • Tools are cached in-memory for the connection lifetime
  • Cache persists across multiple conversations
  • Cache is cleared when user disconnects or connection fails
  • No automatic refresh mechanism
  • To update tools, users must disconnect and reconnect

Tool Execution

When an agent decides to use a tool, Poke calls tools/call: Request:
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "search_repositories",
    "arguments": {
      "query": "machine learning"
    }
  },
  "id": 3
}
Expected Response:
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Found 3 repositories:\n1. tensorflow/tensorflow\n2. pytorch/pytorch\n3. scikit-learn/scikit-learn"
      }
    ]
  }
}
Execution Context:
  • Called by Poke’s execution agent (not user-facing agents)
  • Agent decides when to call tools based on:
    • Tool descriptions
    • Server instructions
    • Conversation context
    • User intent
  • Multiple tools can be called in sequence
  • Results are passed to user-facing agent for response generation

Authentication

Supported Methods

Poke implements three authentication patterns:

1. No Auth

Use case: Public integrations without user credentials Implementation:
  • No authentication header sent
  • Server must allow unauthenticated access
  • User adds integration with URL only

2. API Key

Use case: Simple token-based authentication Implementation:
  • User provides API key during setup
  • Poke stores key securely (encrypted at rest)
  • Key sent in Authorization header:
    Authorization: Bearer <user_api_key>
    
Server validation:
  • Validate token on every request
  • Return 401 for invalid/expired tokens
  • Support key rotation (users can update key in settings)

3. OAuth 2.0

Use case: Delegated access to user accounts Implementation:
  • Authorization Code flow with PKCE
  • User redirects to your OAuth page
  • User authorizes integration
  • Poke exchanges code for access token
  • Tokens stored securely (encrypted at rest)
  • Automatic token refresh using refresh token
Required OAuth endpoints:
  • Authorization URL: Where users authorize
  • Token URL: For code exchange and refresh
  • Supports PKCE (RFC 7636)
Headers sent:
Authorization: Bearer <access_token>
Token refresh:
  • Automatic when access token expires
  • Uses refresh token to obtain new access token
  • If refresh fails, user must re-authorize
See Authentication for implementation details.

Error Handling

Standard Error Codes

Poke handles these JSON-RPC error codes:
CodeMeaningPoke Behavior
-32700Parse errorLog error, show connection failed
-32600Invalid RequestLog error, retry with corrected request
-32601Method not foundLog error, mark capability as unsupported
-32602Invalid paramsLog error, show tool execution failed
-32603Internal errorShow error to user, allow retry
401UnauthorizedPrompt user to re-authenticate
403ForbiddenShow permission error to user
404Not FoundShow “Integration not found” error
429Rate LimitedExponential backoff, show rate limit message
500-599Server ErrorShow error to user, allow retry

Authentication Errors

401 Unauthorized:
  • API Key: Prompt user to update key
  • OAuth: Attempt token refresh, then prompt re-authorization if refresh fails
  • No Auth: Show error (misconfigured server)
403 Forbidden:
  • Show “Insufficient permissions” error
  • For OAuth: Suggest re-authorization with additional scopes

Connection Errors

Network timeout:
  • Default timeout: 30 seconds
  • Show “Connection timeout” error
  • Allow retry
Connection refused:
  • Show “Cannot reach server” error
  • Suggest checking server URL and network
SSL/TLS errors:
  • Require valid SSL certificate
  • Show certificate error details
  • Do not allow insecure connections

Rate Limiting

Poke does not implement client-side rate limiting. Your server should: Implement rate limits:
  • Return 429 status code with Retry-After header
  • Include error message describing limit
Example response:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 5,
  "error": {
    "code": 429,
    "message": "Rate limit exceeded. Try again in 60 seconds."
  }
}
Poke behavior:
  • Respects Retry-After header
  • Shows rate limit message to user
  • Prevents further calls until retry time

Implementation Checklist

Use this checklist to ensure MCP compliance:

Protocol

  • Implement protocol version 2025-06-18 or 2024-11-05
  • Support version negotiation during initialization
  • Handle initialize and initialized messages

Transport

  • Expose HTTPS endpoint (not HTTP)
  • Implement Streamable HTTP transport
  • Optionally support SSE for backward compatibility

Capabilities

  • Respond to tools/list with tool schemas
  • Implement tools/call for tool execution
  • Return valid JSON-RPC responses

Metadata

  • Provide name and version in server info
  • Optionally provide title for UI display
  • Include instructions with guidance for agents

Authentication

  • Choose authentication pattern (No Auth, API Key, or OAuth)
  • Validate credentials on every request
  • Return 401 for authentication failures

Error Handling

  • Return standard JSON-RPC error codes
  • Include descriptive error messages
  • Implement rate limiting with 429 responses

Tools

  • Provide clear, descriptive tool names
  • Write comprehensive tool descriptions
  • Define complete JSON schemas for parameters
  • Return structured, informative results

Testing Your Integration

Local Testing

  1. Use MCP Inspector:
    npx @modelcontextprotocol/inspector <your-command>
    
    Web-based tool for testing MCP servers
  2. Use Claude Desktop:
    • Supports stdio for local testing
    • Test tool discovery and execution
    • Validate server instructions

Deployment Testing

  1. Deploy to HTTPS endpoint
  2. Add integration in Poke:
  3. Test in conversations:
    • Ask questions that should trigger your tools
    • Verify agent uses tools appropriately
    • Check tool results are accurate

Debugging

Check connection logs:
  • Initialization handshake
  • Protocol version negotiation
  • Tool discovery response
  • Authentication success/failure
Common issues:
  • Tools not being called: Review server instructions, improve tool descriptions
  • Authentication failures: Verify token/OAuth implementation
  • Connection timeouts: Check server response time (<30s)
  • Transport failures: Ensure HTTPS endpoint is accessible

External References