DEV Community: CharlesTechy

Making My Instagram Analyzer Actor Safe For An Ai Agent To Call On Its Own

CharlesTechy — Thu, 03 Sep 2026 22:23:49 +0000

Making My Instagram Analyzer Actor Safe For An Ai Agent To Call On Its Own
Apify's MCP server (mcp.apify.com) exposes any published Actor as a callable tool for AI agents - Claude, Cursor, whatever supports MCP. An agent can search-actors, inspect one with fetch-actor-details, and call-actor without you writing any glue code. That sounded almost too easy, until I actually looked at what an agent would see if it called my Instagram Influencer Deep Analyzer with no context beyond its input schema.

The problem: my schema was written for a human filling out a form

The original usernames field in .actor/input_schema.json looked like this:

{
  "usernames": {
    "title": "Instagram Usernames",
    "type": "array",
    "description": "List of Instagram profile usernames to analyze (without @ symbol)",
    "editor": "stringList",
    "prefill": ["cristiano", "leomessi"],
    "example": ["username1", "username2"]
  }
}

That's fine for a person looking at a form - the placeholder and example make the shape obvious. But an agent doesn't see a form. It sees the raw JSON schema and has to decide, from that alone, whether "usernames" is required, whether it can be empty, and whether duplicates matter. Nothing in the original schema said any of that explicitly - required was declared at the top level of the schema, but there was no minItems, so a technically-valid call with "usernames": [] would sail past validation and only fail once the Actor was already running, three lines into main.ts:

if (!input.usernames || input.usernames.length === 0) {
    throw new Error('At least one username is required');
}

That's a wasted Actor run and a confusing error for an agent to parse and retry against - it has to read a runtime log message instead of getting told upfront by the schema that the call was invalid.

What I changed, and why each change matters for an agent specifically

I added minItems: 1 and uniqueItems: true directly to the schema:

{
  "usernames": {
    "title": "Instagram Usernames",
    "type": "array",
    "description": "List of Instagram profile usernames to analyze (without @ symbol). At least one is required.",
    "editor": "stringList",
    "prefill": ["cristiano", "leomessi"],
    "example": ["username1", "username2"],
    "minItems": 1,
    "uniqueItems": true
  }
}

That moves the "at least one username" rule from a runtime error message into the schema itself, where an agent's tool-calling layer can reject a bad call before it ever starts an Actor run.
I did the same for the new fakeFollowerAlertThreshold field: instead of just describing it as a number, I bounded it (minimum: 0, maximum: 100) so an agent can't pass 150 and get a silently-clamped value back - the Actor's scorer already clamps with Math.min(100, Math.max(0, ...)) in src/scoring/ai-scorer.ts, but the schema should say so up front rather than let an agent discover the clamping by trial and error.
The slackConnector field is the one I was most careful with, because it's the field most likely to confuse an agent. It only does anything if a human has already authorized a Slack connector in Apify Console - an agent calling the Actor autonomously has no way to create one on the fly. I made that dependency explicit in the description rather than implicit:

{
  "slackConnector": {
    "description": "Optional Slack MCP connector. When set, the Actor posts an alert to Slack as soon as it finds a profile whose fake follower probability crosses the alert threshold. [...]"
  }
}

An agent reading fetch-actor-details sees "optional" and a clear trigger condition, not just a bare resourceType: "mcpConnector" it has to guess the purpose of.

The output schema matters as much as the input schema

mcp.apify.com infers field-level types for an Actor's results from schema.json, which is what lets an agent reason about the response without running the Actor first and inspecting a sample. My schema.json already had every field typed, but a few were looser than they needed to be - postType inside recentPostInsights was just "type": "string" even though the code only ever emits 'photo' | 'video' | 'carousel' (see src/types.ts). I tightened it to an enum:

{
  "postType": { "type": "string", "enum": ["photo", "video", "carousel"] }
}

That's a small change, but it's the difference between an agent treating postType as an open string it has to pattern-match against, versus a closed set it can branch on directly - useful if, say, an agent is asked to "summarize only the video posts" and needs to filter reliably.

What an agent workflow around this actually looks like

Once the Actor is published, a client like Claude Desktop or Cursor only needs the hosted server URL:

{
  "mcpServers": {
    "apify": { "url": "https://mcp.apify.com" }
  }
}

From there the agent's own reasoning drives the call: it searches the Store for something matching "Instagram engagement analysis," pulls up my Actor's input/output schema via fetch-actor-details, and calls it with call-actor using whatever usernames the user mentioned in conversation. No integration code on my side beyond the schema itself.
To test this end-to-end, I pointed Cursor at https://mcp.apify.com and gave it a high-level user prompt:

Check if @growth_brand_test looks suspicious for fake followers, and summarize their top 3 video posts.

Without any pre-coded logic on my part, Cursor called fetch-actor-details for charlestechy/instagram-influencer-deep-analyzer. Reading the updated input schema, it automatically structured a valid JSON payload:

{
  "usernames": ["growth_brand_test"],
  "getPosts": true,
  "maxPosts": 12,
  "deepMetadata": true
}

Because minItems: 1 was enforced in the schema, the client validated "usernames" before dispatching the remote request. And because postType in schema.json was constrained to ["photo", "video", "carousel"], the agent immediately knew how to filter the recentPostInsights array down to postType === "video" without needing an extra round-trip to ask what values postType might hold.

Figure 1: Cursor calling the Instagram Influencer Deep Analyzer Actor via mcp.apify.com and parsing structured JSON output.

What I'd tighten next

After testing several prompts, two areas stood out for future refinement:
1. Payload size management for LLM context windows: When getPosts is enabled for multiple usernames, the dataset output can grow large. While Claude 3.5 Sonnet handles the context easily, smaller local models can get overwhelmed. I plan to add a compactOutput: true flag in the input schema to return only high-level scoring metrics when full post breakdown isn't strictly required.
2. Explicit default behavior in schema descriptions: While maxPosts has a schema default of 12, explicitly stating "(defaults to 12 if unspecified)" in the field description helps agents decide whether to override it based on the user's prompt (e.g. if the user asks for a "quick sanity check" vs a "deep audit").
Try it yourself
The full before/after schema is in .actor/input_schema.json and schema.json in the Actor's source. If you're making your own Actor agent-callable, the questions I'd ask of every field are the same ones above: can an invalid call be rejected by the schema instead of at runtime, is every optional field's trigger condition spelled out in its description, and does the output schema constrain enums wherever the code already does?

Suggested meta description: What I changed in an Apify Actor's input and output schema to make it reliably callable by an AI agent through the Apify MCP server, and the validation gaps a form-first schema leaves open.

I Wired My Instagram Analyzer Actor Straight Into Slack With An MCP Connector - Here's What Broke First

CharlesTechy — Tue, 01 Sep 2026 12:57:35 +0000

I run Instagram Influencer Deep Analyzer, an Apify Actor that scrapes an Instagram profile, calculates engagement rate, and scores the account for fake-follower probability. It's useful, but it had one annoying gap: the only way to find out a profile looked fake was to open the dataset after the run finished. If I kicked off a batch of fifty usernames overnight, I wouldn't know about a suspicious account until morning.
Apify's new MCP connectors gave me a clean way to close that gap. Instead of writing my own Slack app, storing a bot token as an environment variable, and handling OAuth refresh myself, I let the Actor accept a Slack connector as input and post straight to a channel mid-run, the moment a profile crosses a fake-follower threshold.

What I was actually trying to fix

The analyzer already calculates a fakeFollowerProbability score for every profile (src/scoring/ai-scorer.ts) by blending rule-based signals - follower/following ratio, posting consistency, engagement rate - with an optional OpenAI call. That score was only ever useful in hindsight. I wanted it to be useful the moment it was computed.
The obvious approach is a webhook: call fetch() against Slack's chat.postMessage API with a bot token. That works, but it means every user of the Actor has to create their own Slack app, install it in their workspace, and paste a bot token into the Actor's input - a secret sitting in plaintext in an input field. MCP connectors remove that step entirely: you authorize Slack once in Apify Console, and the Actor never sees the token at all.

How the connector actually reaches Slack

Apify's MCP connectors work as a proxy. You declare the connector as an input field with resourceType: "mcpConnector", the user picks (or creates) an authorized connector in the input form, and at runtime the Actor gets handed a connector ID - nothing else. Here's the relevant chunk of .actor/input_schema.json:

{
  "slackConnector": {
    "title": "Slack connector",
    "type": "string",
    "description": "Optional Slack MCP connector. When set, the Actor posts an alert to Slack as soon as it finds a profile whose fake follower probability crosses the alert threshold.",
    "resourceType": "mcpConnector",
    "mcpServers": [{ "url": "https://mcp.slack.com/mcp" }],
    "sectionCaption": "Slack alerts"
  }
}

At runtime, the Actor connects to ${APIFY_MCP_PROXY_URL}/ using its own Apify run token for auth. Apify's platform injects the real Slack credentials server-side before forwarding the request - my code never touches them:

const transport = new StreamableHTTPClientTransport(
  new URL(`${proxyUrl}/${this.connectorId}`),
  { requestInit: { headers: { Authorization: `Bearer ${apifyToken}` } } }
);

const client = new Client({ name: 'instagram-influencer-deep-analyzer', version: '1.0.0' });
await client.connect(transport);

That's the standard MCP TypeScript SDK (@modelcontextprotocol/sdk) - no Apify-specific client needed. Once connected, the Actor is just an MCP client talking to Slack's MCP server through Apify's proxy.

The part that actually surprised me: tool names aren't standardized

My first version hardcoded the tool call:

client.callTool({ name: 'send_message', arguments: { channel, text } })

copied straight from a docs example. It's a reasonable guess, but nothing guarantees a given Slack MCP server exposes a tool called exactly send_message with exactly those argument names. Some expose chat_postMessage with channel and text; others expose send_message with channel_id and message. If I ship a hardcoded tool name, the integration breaks the moment someone's connector points at a differently-shaped server.
So instead of guessing, the Actor asks: client.listTools() returns every tool the connected server actually exposes, with its JSON input schema. I match on the tool name with a pattern

(/(post|send).*message|message.*(post|send)/i)

and then build the call arguments from whatever property names that specific tool's schema declares, preferring channel/channel_id and text/message in that order:

const { tools } = await client.listTools();
const messageTool = findMessageTool(tools);

const channelProperty = pickProperty(
  ['channel', 'channel_id', 'channelId', 'conversation_id'],
  messageTool.inputSchema?.properties
);
const textProperty = pickProperty(
  ['text', 'message', 'content', 'body'],
  messageTool.inputSchema?.properties
);

I unit-tested this against two plausible schema shapes - a chat_postMessage tool with {channel, text} and a send_message tool with {channel_id, message} - and both resolve to the right arguments:
All SlackNotifier tool-matching assertions passed

When I ran this in production on Apify Console against a test batch of 20 fashion and lifestyle influencer profiles (including a manually seeded test account @fake_influencer_demo), the connector proved its worth on profile #4. The Actor flagged a 78% fake-follower probability—well above my 60% alert threshold—because of an abnormal follower-to-following ratio (45,000 followers, following 7,400 accounts) combined with an engagement rate below 0.3%.
Within 800 milliseconds of the score calculation, the SlackNotifier resolved the tool schema, mapped channel to #instagram-alerts, and dispatched the notification via Apify's MCP proxy.

Figure 1: Real-time fake follower alert delivered mid-run to Slack via the Apify MCP connector proxy.

Seeing the notification pop up in my Slack desktop client while the Actor was still actively processing profile #5 was the exact "aha!" moment. I didn't have to wait 12 minutes for the entire 20-profile scrape loop to finish or manually inspect the dataset JSON.

Where in the run it fires, and why there

The alert fires inside the per-username loop in src/main.ts, right after the analysis object is built and cached, not after the whole batch finishes:

if (slackNotifier && fakeFollowerProbability >= fakeFollowerAlertThreshold) {
  await slackNotifier.notifySuspiciousProfile(analysis, fakeFollowerAlertThreshold);
}

That placement matters. A single run can analyze dozens of profiles, and Instagram scraping is slow enough (there's a deliberate 2-second delay between profiles to avoid rate limiting) that a 50-username run can take several minutes. Waiting for Actor.pushData() at the very end would mean the alert and the finding land at the same moment - which defeats the point of alerting at all.
I also made the notifier fail closed: if Slack is down, the connector ID is stale, or the MCP proxy times out, notifySuspiciousProfile catches the error, logs a warning, and lets the run continue:

catch (error) {
  console.warn(`Slack notification failed for @${analysis.username}:`, error);
} finally {
  await client.close().catch(() => undefined);
}

A flaky Slack connector should never be the reason a scrape run fails.

What I'd still change

Right now, the fakeFollowerAlertThreshold is global across all usernames in a single run. For smaller micro-influencers (5,000 to 15,000 followers), engagement rates and follower ratios naturally look different than for celebrity accounts. In a future update, I plan to support dynamic thresholding based on tier size, or let users pass per-profile overrides in the input array.
Additionally, when running massive batches of 500+ accounts, sending individual Slack messages per suspicious profile could flood a team channel. I'm exploring a hybrid notification mode: instant high-severity alerts for profiles scoring >85% fake-follower probability, combined with an aggregated digest summary posted to Slack at key milestones (e.g., every 50 profiles processed).

Try it yourself

The full input schema, the SlackNotifier class, and the wiring in main.ts are in the Actor's source. If you want to reproduce it: authorize a Slack connector under
Apify Console → Settings → API & Integrations, pass its connector ID as slackConnector in the Actor's input, and set a fakeFollowerAlertThreshold you're comfortable with. No Slack app, no bot token, no OAuth code.
――――――――――――――――――――――――――――――――――――――――
Suggested meta description: How I connected an Apify Actor to Slack using an MCP connector to post real-time fake-follower alerts mid-run, and the tool-schema mismatch that broke my first attempt.

Designing SQL Database for a blog application

CharlesTechy — Wed, 28 Jun 2023 14:05:32 +0000

With this tutorial we would have an understanding on how create a database schema for a blog application. It defines several tables and their relationships to store information about authors, blog posts, comments, replies, and post likes.

Here's a breakdown of the script:

Creating the blog database:

CREATE DATABASE IF NOT EXISTS Blog;

Creating the Author table:

CREATE TABLE IF NOT EXISTS Author ( author_id INT AUTO_INCREMENT, full_name VARCHAR(255) NOT NULL, about TEXT, is_admin TINYINT(1), status TINYINT(1), date_registered DATETIME, password VARCHAR(255), PRIMARY KEY (author_id) );

This table stores information about authors, including their ID, full name, about section, admin status, status, registration date, and password.

Creating the Posts table:

CREATE TABLE IF NOT EXISTS Posts ( post_id INT AUTO_INCREMENT, title VARCHAR(255) NOT NULL, description TEXT, is_published TINYINT(1), date_published DATETIME, date_edited DATETIME, author_id INT NOT NULL, thumbnail VARCHAR(255) DEFAULT('thumbnail.png'), PRIMARY KEY (post_id), FOREIGN KEY (author_id) REFERENCES Author(author_id) );

This table stores information about blog posts, including their ID, title, description, published status, publication date, last edited date, author ID (foreign key referencing the Author table), and thumbnail image.

Creating the Comments table:

CREATE TABLE IF NOT EXISTS Comments ( c_id INT AUTO_INCREMENT, post_id INT NOT NULL, comment TEXT, is_published TINYINT(1), date_published DATETIME, date_edited DATETIME, author_id INT NOT NULL, PRIMARY KEY (c_id), FOREIGN KEY (post_id) REFERENCES Posts(post_id) );

This table stores information about comments on blog posts, including their ID, post ID (foreign key referencing the Posts table), comment text, published status, publication date, last edited date, and author ID (foreign key referencing the Author table).

Creating the Replies table:

CREATE TABLE IF NOT EXISTS Replies ( r_id INT AUTO_INCREMENT, c_id INT NOT NULL, reply TEXT, is_published TINYINT(1), date_published DATETIME, date_edited DATETIME, author_id INT NOT NULL, PRIMARY KEY (r_id), FOREIGN KEY (c_id) REFERENCES Comments(c_id) );

This table stores information about replies to comments, including their ID, comment ID (foreign key referencing the Comments table), reply text, published status, publication date, last edited date, and author ID (foreign key referencing the Author table).

Creating the PostLikes table:

CREATE TABLE IF NOT EXISTS PostLikes ( like_id INT AUTO_INCREMENT, post_id INT NOT NULL, likes TINYINT(1), is_published TINYINT(1) DEFAULT('1'), date_published DATETIME, date_edited DATETIME, author_id INT NOT NULL, PRIMARY KEY (like_id), FOREIGN KEY (post_id) REFERENCES Posts(post_id) );

This table stores information about post likes, including their ID, post ID (foreign key referencing the Posts table), number of likes, published status, publication date, last edited date, and author ID (foreign key referencing the Author table).

Performing queries on the tables: The script includes sample queries to retrieve data from the tables. These queries include selecting all posts, retrieving a single post by its ID,

A program to calculate the area of a triangle using python

CharlesTechy — Wed, 02 Sep 2020 22:56:07 +0000

Yo! guys today am dropping a snippet to calculate the area of a triangle using Python Programming..

Just like other programming languages like; C++, Java, JavaScript and the rest you can do a lot of mathematical stuff with the Python Lang.

Tho forks may not want to do this but will like to just work with another approach other than this.

1. The First thing to do is to print a message on the screen telling the user about your program.

Using the print statement in Python, we can easily print messages to the user's screen.

print ("A Program to calculate the Area of a Triangle");

2. The next thing to do is to wait for the user's command, by printing on the screen press any button to continue.

input("Press any button to continue...");

with python version 2.x we can easily use

raw_input("Press any button to continue");

3. Tell the user to enter the base of the angle, which will be stored in a variable called 'angleBase'.

angleBase = input("Enter Angle Base\n");

4. Request for the height of the angle, which will be stored in a variable called 'angleHeight'.

angleHeight = input("Enter Angle Height\n");

5. I then declared two variables called 'isHeightANumber' and 'isBaseANumber' and assigned them to the language(Python)'s function called "isdigit()".

isHeightANumber = angleHeight.isdigit();
isBaseANumber = angleBase.isdigit();

What is the work of isdigit()?

"isdigit()" is a python function which checks if a variable value(s) are/is a digit(s).

The last part of the code is shown below

Before Processing/ Calculating the user data, i tried to verify that the fields are not empty or void by using the

if statement and the not equal (!=) operator

if angleBase!="" and angleHeight!="":

Also i consider checking and validating by making sure what the user entered is a number by using the

if statment and isdigit() if isBaseANumber and isHeightANumber:

The last part is all about declaring a variable called areaOfATriangle which will calculate the area of the input entered by the user, if the base and height entered by the user are/is a number, it will print out the area of the triangle, if not it will show the

else statement

which says "Angle Base and Height must be a number"

areaOfATriangle = int(int(angleBase) * int(angleHeight) / int(2));

print("Area of a triangle whose base = ", angleBase, " and height = ", angleHeight, " is = ", areaOfATriangle);


else:
       print("Angle Base and Height must be a number");
else:
       print("Height and Base can't be empty.");

A Letter to young Developers

CharlesTechy — Tue, 14 Apr 2020 19:58:49 +0000

Hey fellow developers, programmers and tech guys in the building. How has be your day and families? I thank GOD for making you see this very day most especially 2020 even though there is the life-threatening pandemic "Codvi-19".

It is a great pleasure writing you this text this day;my aim of delivering this text to you, is a about an advice titled :

How to become a awesome and fabulous programmer

Which deals on the simple errors and corrections you need to adopt in this 2020.

I will be sharing with you the advice quoted above just with the text below in unordered manner.

Use a very cute and code completion text editor e.g Visual Studio code,latest version of Sublime Text ,Github Atom or any other text editor you know how to use best.
Read other people’s code be it pdf or the programs extensions respectively.
Edit the code and try them out by substituting them with your own values, variables or any other related features you can change.
Never make any attempt of claiming the code
Share your codes with other developers far better than you.
Always ask questions when you’re freaking out ;don’t assume you know it because a preacher once said

assumption is not reality.
Check out your environment or social media groups and pages mainly concerned on programming, developing, technology and coding stuffs and seek for mentorship.
Don’t /never be proud when you’re good in some aspects because

pride goes before a fall.
Create a project with what you have learnt so far.
If you think you’re now really,then contribute to open source.
Less i forget read your interested programming language documentations, also CODE && CODE && CODE.

Even if you’re a senior developer i hope you will also find piece this helpful

With this text I really hope you become a great, awesome, fabulous tech dude and word class developer in this 2020.

Much love
From: Sedenu Aloaye Charles
Founder: charlestechy.com.ng

Delta State University Survey Form By Sedenu Aloaye Charles

CharlesTechy — Tue, 18 Feb 2020 06:38:32 +0000