Skip to main content
Glama
thenavidm

bluesky-mcp

by thenavidm

Read a profile

get_profile
Read-onlyIdempotent

Fetch full Bluesky profiles for up to 25 handles or DIDs, including bio, follower counts, labels, and follow relationship details when a connected account is available. Works without credentials.

Instructions

Full profile for one or more accounts: bio, follower counts, labels, and, when a connected account is available, whether you follow them and whether they follow you. Works without credentials.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorsYesHandles (with or without @) or DIDs. Up to 25 in one call.
accountNoWhich connected account to act as, by handle (for example 'alice.bsky.social' or just 'alice'). Defaults to the first connected account. Call list_accounts to see them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.0.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv1.1.1

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds real behavioral context beyond that: it works without credentials, and follow/follower-relationship data is only present 'when a connected account is available' – a conditional result shape the agent would otherwise not anticipate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence delivers the resource, the returned fields, and the conditional behavior, followed by a two-word credential note. No filler, no repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations carrying the safety profile and no output schema required, the description covers the essentials: scope, returned fields, credential independence, and conditional relationship data. It stops short of noting behavior for invalid handles or how many profiles are returned per call, but these are minor omissions for a read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with both the actors array (handles/DIDs, up to 25) and the account selector fully documented in the schema. The description only echoes the batch nature ('one or more accounts') and hints that the account parameter drives the follow-relationship enrichment; it adds little syntax or format detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (profile) and enumerates exactly what it returns: bio, follower counts, labels, and relationship status. It is clearly distinguishable from siblings like search_actors (discovery) and get_followers (list retrieval) because it returns a per-account profile bundle.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides one genuinely useful usage cue – 'Works without credentials' – which tells the agent this call is available even in an unauthenticated context. However, it never states when to prefer this over search_actors, get_relationships, or whoami, so routing guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.