Connect tickerseer to your assistant.

Three steps, about two minutes. You need a tickerseer account and one of the clients below. There is no API key at any point: you approve the connection once in a browser, the same way you would authorize any other app.

If something goes wrong, skip to Troubleshooting. Two of the failures listed there report success and leave you misconfigured, so it is worth reading even when the commands appear to have worked.

Step 1. Add the server.

Step 2. Approve the connection.

Step 3. Check that it worked.

Troubleshooting.

Claude Code connected but has no tickerseer tools.

Run claude mcp list. It health-checks each server and prints the reason a tool list was refused, which is the one place that reason appears: inside a session the tools are simply absent, and the assistant can only tell you it has none.

If it reports the server as connected with tools listed, and your session still cannot see them, quit Claude Code and start it again. Tools are collected when a session starts, so a server authenticated part-way through an existing session may not be picked up until the next one.

The connection itself is separate from the tool list, and you can check it without either: the app appears on your account page under Apps connected over MCP the moment the sign-in completes, whether or not your assistant can see the tools yet.

Codex said it added the server, but there are no tickerseer tools.

Look at the entry it wrote. It should read url = "https://tickerseer.com/mcp". If it reads command = "--url" instead, the -- separator went in and the server was recorded as a local program. Remove that entry and run the line from step 1 again.

It says I am not authorized, and it worked yesterday.

The connection was most likely disconnected, from your account page or by someone with access to it. Check the Apps connected over MCP list: if it is gone, run step 1 again and approve. Access is also short-lived by design and your client renews it on its own, which you would never see, so that is not the explanation here.

Some tools work and others are refused.

That is intended, and the refusal says which of the two reasons applies. A permission you did not approve is fixed by connecting again and approving it. A feature above your plan is not: approving again changes nothing, and the message says so rather than sending you back round the sign-in loop for a second time.

A plan change takes effect on the next request, but your client may still be showing a tool list it cached earlier. The refusal is current even when the list is not.

Requests start failing after a burst of activity.

There is a per-connection limit, and an assistant working down a long list of stocks reaches it faster than a person would. Wait a minute and carry on; nothing is lost. Asking tickerseer questions is metered separately and draws on one daily allowance shared with the website, so questions asked here count against the ones asked there.

My client is not one of the two listed.

It may well work. The connector follows the MCP specification and answers both the current protocol version and the older one, which is what the two clients above use between them. We list only what we have watched connect from start to finish, so an absent client means untested rather than unsupported. Tell us which one you use and we will test it.

I am writing my own client.

Set a User-Agent header explicitly. The default that some HTTP libraries send is rejected at our edge before the request reaches the application, which from the outside looks the same as a broken endpoint and leaves nothing in our logs to point at.

I want to disconnect it.

Open your account page, find the app under Apps connected over MCP, and select Disconnect. It stops working on its next request, and reconnecting means approving the permissions again.