Skip to main content
Glama

UseMyContext.ai

by io.github.usemycontext

List your profiles

list_profiles
Read-only

List the user's own profiles (their projects). Returns metadata only for each profile: its projectId, its name, its public @handle, its privacy status (private, shared, network, public, or org), and whether it is the one THIS connection reads by default. Use it when the user asks how many profiles they have, what their profiles are called, or which profile you are connected to - and whenever another tool needs a projectId to target a specific profile, because each entry carries its projectId. Do NOT use it to read the user's context, to learn about them, or to set them up with UseMyContext - the profile tool does all three. No file content, no facts, no compiled context. Read-only; nothing is written, so it is safe to call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
profilesYes
activeProjectIdYesThe projectId this connection reads by default (matches the active profile).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

The description reinforces the readOnlyHint annotation by stating 'Read-only; nothing is written, so it is safe to call.' It also adds beyond annotations by disclosing that only metadata is returned—no file content, facts, or compiled context—which gives the agent a precise model of the tool's behavior.

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

Conciseness4/5

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

The description is somewhat long but every sentence adds actionable content: purpose, return metadata, use cases, exclusions, and safety. The no-content phrasing ('No file content, no facts, no compiled context') slightly repeats the 'metadata only' point, but the structure is otherwise efficient and front-loaded.

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

Completeness5/5

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

For a parameterless, read-only tool with an output schema, the description is fully complete. It tells the agent exactly what the tool returns, when to invoke it, when to avoid it, and which sibling to use instead. No critical information is missing.

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

Parameters4/5

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

The tool has zero parameters, so there is no parameter documentation burden. The schema's coverage is effectively 100% with an empty properties object, and the description appropriately focuses on behavior and output rather than parameters.

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 states a specific verb and resource: it lists the user's own profiles and specifies the exact metadata fields returned. It also explicitly differentiates from the sibling 'profile' tool, making it impossible to confuse the two.

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

Usage Guidelines5/5

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

The description gives clear when-to-use cases: counting profiles, naming profiles, identifying the connected profile, and supplying projectId to other tools. It explicitly says when NOT to use it, pointing to the 'profile' tool for reading context or setting up UseMyContext.

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

All UseMyContext.ai toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation3/5

Most tools have clear boundaries, but fetch/get_file and search/search_files are explicit aliases of each other, creating redundant purposes. account vs info and list_files vs search_files also require careful reading to tell apart, though the descriptions do provide guidance.

Naming Consistency3/5

The set mixes verb_noun names (list_files, query_table, suggest_update) with standalone nouns (account, info, profile) and bare verbs (fetch, search). The naming is readable and lowercase throughout, but the conventions are not uniform.

Tool Count5/5

Thirteen tools is a reasonable, well-scoped number for a personal-context and document-access server. The two alias pairs add some redundancy but do not make the set feel bloated.

Completeness4/5

The server covers the core read-only workflows: discovering files, searching semantically, querying tabular data, retrieving full documents, reading profiles, and accessing shared context. Direct profile editing or file mutations are intentionally out of scope for this read-only connection, and suggest_update provides the one sanctioned write path.

Resources