MCP Server

How to connect to nicoolAI over MCP: discovery, dynamic client registration, OAuth, the single get_response tool, and attachment rules.

nicoolAI exposes a narrow MCP server for agent-to-agent use.

The intent is simple: authenticate with standard MCP OAuth, send one prompt plus file attachments, and get back one text response. This is not a public mirror of nicoolAI's internal tool graph.

What this server is for

Use the MCP server when you want another MCP-capable client or agent to ask nicoolAI for a response inside a larger workflow.

Today, the public MCP surface is intentionally small:

one MCP server endpoint
OAuth with dynamic client registration
one tool: get_response
text output only

That keeps the external contract stable while the internal runtime continues to evolve.

Discovery and auth

Start from the protected resource metadata at the root origin:

GET /.well-known/oauth-protected-resource

That document points MCP clients at the authorization server. From there, read the advertised OAuth metadata and use the advertised endpoints rather than hardcoding paths.

In practice, the flow is:

Read /.well-known/oauth-protected-resource
Read the advertised authorization server metadata
Register a client through the advertised registration_endpoint
Complete the authorization code flow with PKCE
Call the MCP endpoint with the resulting bearer token

If a client calls a protected MCP tool without a valid bearer token, nicoolAI returns a WWW-Authenticate challenge with resource_metadata, which is the standard MCP OAuth recovery path.

MCP endpoint

Send MCP requests to:

/api/mcp

The server is request/response oriented. It does not expose nicoolAI's internal tools directly.

Available tool

`get_response`

Use this when you want nicoolAI to read a prompt, optionally inspect attached files, and return a single text answer.

Input:

{
  "prompt": "Summarize the attached report and tell me what changed from last quarter.",
  "attachments": [
    {
      "type": "file",
      "url": "https://example.com/q1-report.pdf",
      "filename": "q1-report.pdf",
      "mediaType": "application/pdf"
    }
  ]
}

Output:

MCP tool content containing one text item

Example result shape:

{
  "content": [
    {
      "type": "text",
      "text": "The report shows revenue growth, weaker margins, and two major hiring changes..."
    }
  ]
}

Attachment rules

Attachments are explicit file objects. Do not rely on nicoolAI to scrape attachment URLs out of the prompt body.

Supported attachment input

public http or https URLs
optional filename
optional mediaType
Google Drive or Docs shared links passed as attachment URLs

Not supported in the public contract

nicoolAI asset IDs
data: URLs or base64 payloads
localhost URLs
private-network IP targets

nicoolAI fetches public attachment URLs, ingests them privately, and then runs the normal internal attachment pipeline.

Google Drive behavior

Google Drive links can be passed as attachment URLs.

If the authenticated nicoolAI user has the right Google Drive connection, nicoolAI will resolve and read the linked material through the existing Drive flow. If that connection is missing, the response should explain that the account needs to connect Google Drive instead of pretending the file was available.

Current limits

The MCP server is intentionally narrow right now.

no public profile selection
no public structured-output contract
no public exposure of internal tools like bash or search
no public asset handles
no inline attachment parsing from prompt text

The current design goal is reliability for sub-agent use, not broad external surface area.

When not to use this

Do not use the MCP server if you need:

direct access to nicoolAI's internal tool graph
long-running delegated task state
streamed work updates or task orchestration
a stable public artifact API

In those cases, the MCP server is too narrow by design.