Strava MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources and actions in the Strava domain. For example, get_activity retrieves a single activity by ID, while list_activities lists multiple activities; explore_segments searches segments by area, while get_segment gets a specific segment by ID. There is no overlap or ambiguity in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as get_activity, list_activities, explore_segments, and get_segment_efforts. This uniformity makes the tool set predictable and easy to understand for agents.
Tool Count5/5
With 8 tools, the server is well-scoped for interacting with Strava's API, covering athlete profiles, activities, and segments without being overwhelming. Each tool serves a distinct and necessary function, such as retrieving data or listing resources, making the count appropriate for the domain.
Completeness4/5
The tool set provides strong coverage for reading athlete data, activities, and segments, including CRUD-like operations like get and list. However, there are minor gaps, such as no tools for creating or updating activities or segments, which might limit full lifecycle management but are not critical for common query-focused workflows.
Average 3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get efforts' suggests a read operation, but the description doesn't specify what 'efforts' are (athlete attempts? performance metrics?), whether this requires authentication, what format the results come in, or if there are rate limits. For a tool with 4 parameters and no annotations, this is inadequate behavioral context.
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 extremely concise - just 5 words. While this is efficient, it borders on under-specification rather than optimal conciseness. The single sentence is front-loaded with the core purpose, but could benefit from additional context. It earns points for zero waste but loses one point for being too minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. The agent needs to understand what 'efforts' are, what data structure is returned, whether this requires athlete authentication, and how this differs from related tools. The current description provides only the most basic purpose statement without addressing these contextual needs.
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?
The input schema has 100% description coverage, so all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema - it doesn't explain what 'efforts' are or how the date filtering works. With complete schema coverage, the baseline of 3 is appropriate as the description doesn't add value but doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get efforts on a specific segment' clearly states the verb ('Get') and resource ('efforts on a specific segment'), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'get_segment' or 'explore_segments' - it's unclear what 'efforts' means compared to just getting segment data. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when this is appropriate versus using 'get_segment' for segment metadata, 'list_activities' for broader activity data, or 'explore_segments' for discovering segments. The agent receives no contextual guidance about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral details. It mentions returning 'top 10 segments' (useful context on result limit) but doesn't disclose other traits like rate limits, authentication needs, error handling, or what 'top' means (e.g., by popularity, difficulty). This is inadequate for a search tool with zero annotation coverage.
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 concise with two sentences that efficiently state purpose and result limit. It's front-loaded with the main action. However, it could be slightly more structured by explicitly mentioning the search criteria, but overall it's well-sized with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks details on return format (e.g., what data fields segments include), error cases, or behavioral constraints. For a search tool with 4 parameters, this leaves significant gaps in understanding how to effectively use it.
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 description coverage is 100%, so the schema fully documents all parameters (bounds, activity_type, min_cat, max_cat). The description adds no additional meaning beyond implying search criteria, which is already covered by the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('explore segments') and resource ('in a given area'), specifying it returns top 10 matching segments. It distinguishes from siblings like 'get_segment' (single segment) and 'list_starred_segments' (user-specific), though not explicitly. However, it doesn't fully differentiate from 'get_segment_efforts' which might involve segments, making it a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. It doesn't mention when to prefer 'explore_segments' over 'get_segment' for multiple segments or 'list_starred_segments' for user-specific ones. The description implies search functionality but lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information,' but doesn't specify what that includes, whether it's read-only, requires authentication, has rate limits, or what the output format might be. For a tool with zero annotation coverage, this is a significant gap in transparency.
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?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It directly communicates the tool's function and key constraint, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving detailed activity data) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' entails, potential error conditions, or behavioral traits like safety or performance. For a tool with no structured output documentation, this leaves critical gaps for an AI agent.
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?
The input schema has 100% description coverage, clearly documenting both parameters ('id' and 'include_all_efforts'). The description adds no additional semantic context beyond implying the 'id' parameter is required. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about a specific activity by ID.' It specifies the verb ('Get'), resource ('activity'), and key constraint ('by ID'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_activities' or 'get_segment_efforts,' which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_activities' for browsing activities or 'get_segment_efforts' for activity-related data, nor does it specify prerequisites or exclusions. This lack of context leaves the agent to infer usage scenarios independently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get detailed information' implies a read-only operation, it doesn't address important behavioral aspects like authentication requirements, rate limits, error conditions, or what format the 'detailed information' will be returned in. The description provides minimal behavioral context beyond the basic operation.
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?
The description is perfectly concise - a single sentence that directly states what the tool does without any unnecessary words. It's front-loaded with the core purpose and wastes no space on redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'detailed information' includes, doesn't address authentication or rate limiting concerns, and provides no guidance on error handling. Given the lack of structured metadata, the description should provide more context about the tool's behavior and output.
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?
The schema description coverage is 100% with the single parameter 'id' clearly documented as 'The segment ID'. The description adds no additional parameter semantics beyond what's already in the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and target resource ('about a specific segment by ID'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools like 'get_segment_efforts' or 'explore_segments', which might also retrieve segment-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_segment_efforts' or 'explore_segments'. It mentions retrieving 'detailed information' but doesn't specify what type of information or context would make this the appropriate choice over other segment-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves profile information but doesn't mention authentication requirements, rate limits, error conditions, or response format. This is a significant gap for a tool that likely involves user data access.
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 a single, efficient sentence that front-loads the core purpose. It avoids redundancy and waste, though it could be slightly more structured by separating key points (e.g., authentication context).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves user profile data. It lacks details on authentication, response structure, error handling, and how it differs from sibling tools, making it inadequate for safe and effective use by an agent.
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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately avoids unnecessary information, earning a baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('authenticated athlete's profile information'), including what information is retrieved (name, stats, preferences). It distinguishes from siblings like 'get_athlete_stats' by focusing on profile rather than stats alone, though it doesn't explicitly mention this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_athlete_stats' or 'list_activities'. It implies usage for retrieving profile data but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'authenticated athlete' which implies authentication is needed, but doesn't specify permission requirements, rate limits, pagination behavior (beyond what's in the schema), or what the output looks like. For a list operation with zero annotation coverage, this is insufficient.
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?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's front-loaded with the essential information and appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 2 documented parameters and no output schema, the description is minimally adequate. However, it lacks important context about authentication specifics, output format, and how this differs from sibling tools. With no annotations and no output schema, the description should provide more behavioral guidance to be truly complete.
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 description coverage is 100%, so the schema fully documents both parameters (page and per_page). The description adds no additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('segments starred by the authenticated athlete'), making the purpose immediately understandable. It distinguishes this from general segment tools by specifying 'starred' and 'by the authenticated athlete', though it doesn't explicitly differentiate from all sibling tools like 'explore_segments' or 'get_segment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'explore_segments' or 'get_segment'. It lacks context about prerequisites (e.g., authentication requirements) or typical use cases, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it returns up to 30 activities by default (implying pagination and limits) and specifies it's for the authenticated athlete (implying auth needs). However, it doesn't cover rate limits, error conditions, or what 'activities' entail (e.g., types, fields). The description adds value but lacks comprehensive behavioral context.
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?
The description is appropriately sized and front-loaded, consisting of two concise sentences that directly state the purpose and key constraint (default limit). Every sentence earns its place by providing essential information without waste, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list operation with 4 optional parameters), no annotations, and no output schema, the description is partially complete. It covers the core action and default behavior but lacks details on output format, error handling, or full usage context. It's adequate as a minimum viable description but has clear gaps for a tool without structured support.
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 description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no parameter-specific semantics beyond implying pagination via 'Returns up to 30 activities by default,' which aligns with 'per_page' default but doesn't provide additional meaning. With high schema coverage, the baseline is 3, and the description doesn't compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('the authenticated athlete's activities'), making the purpose specific and understandable. It distinguishes from siblings like 'get_activity' (singular) and 'explore_segments' (different resource), though it doesn't explicitly contrast them. The description is not tautological and provides meaningful context beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), compare with siblings like 'get_athlete_stats' for aggregated data, or specify scenarios where this tool is preferred. Usage is implied by the action but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions authentication context but doesn't disclose rate limits, error conditions, data freshness, or whether this is a read-only operation. The description doesn't contradict annotations, but fails to provide adequate behavioral context for a tool with zero annotation coverage.
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?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a zero-parameter tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides basic purpose but lacks important context. It doesn't explain what specific statistics are returned, their format, or how 'recent activity counts' are defined. Without annotations or output schema, more detail about the return data would be helpful for agent understanding.
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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already documents this completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed statistics for the authenticated athlete'), including what data is returned ('totals and recent activity counts'). It distinguishes from siblings like 'get_athlete_profile' by focusing on statistics rather than profile information, but doesn't explicitly mention all sibling differences.
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?
The description implies usage context through 'authenticated athlete,' suggesting it's for the current user's data. However, it provides no explicit guidance on when to use this versus alternatives like 'get_activity' or 'list_activities' for activity-specific stats, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![strava-mcp-server MCP server](https://glama.ai/mcp/servers/juanlarreapm/strava-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/juanlarreapm/strava-mcp-server)

Score Badge

Copy to your README.md:

[![strava-mcp-server MCP server](https://glama.ai/mcp/servers/juanlarreapm/strava-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/juanlarreapm/strava-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/juanlarreapm/strava-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server