How do I use workday-docs-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@workday-docs-mcp How do I create a sortable grid for expense reports?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

workday-docs-mcp

by philippesimard00

Overview Schema Related Servers Score Discussions

TypeScript

Remote

workday-docs-mcp

An MCP server that grounds an AI coding agent in the Workday developer documentation — so it answers from the real docs and helps build Workday Extend apps correctly, instead of guessing.

Point your IDE agent (Claude Code, Cursor, etc.) at this server and it can search, read, and cite the official Workday docs on demand. With the included Extend builder skill, a developer with no Workday Extend experience can build apps that are grounded in the actual PMD components, functions, and APIs — not plausible-looking hallucinations.

It's a thin, cached layer over the documentation behind developer.workday.com. No login, no API keys, no Workday account required — it reads the public docs.

Why it exists

A general-purpose LLM has almost no Workday Extend in its training data, so it confidently writes invalid PMD (Workday's declarative page metadata) and invents endpoints that don't exist. This server replaces those guesses with retrieved, authoritative reference — and gives the agent the canonical doc link so a human can verify.

Related MCP server: LangChain & LlamaIndex Coding Assistant

What it looks like in use

You: "I'm building a Workday Extend app and want a page that shows a list of expense reports in a table. How do I do that?"
Agent: (calls lookup_extend_reference → grounds on the real grid widget docs) "You'll use the grid widget bound to an inbound endpoint. Here's the PMD, with the real attributes (rows, columns, cellTemplate)… [cites developer.workday.com/wcp_docs/…]"

The agent reaches for the tools on its own (especially with the skill installed), grounds the answer, and links the source.

Tools

Tool	Purpose
`search_workday_docs`	Find docs by concept / widget / API / task → lightweight pointers (title, breadcrumb, `doc_id`, link).
`get_workday_doc`	Fetch a full page as markdown by `doc_id` or a pasted `wcp_docs/<id>.html` link. Always returns the canonical link.
`browse_workday_toc`	Walk the documentation hierarchy when keyword search misses.
`lookup_extend_reference`	Build-focused. Given an intent ("sortable grid", "format a date"), returns the best Extend component / PMD-function / scripting reference page with its content inline + alternatives. Scope with `kind`.

All four tools declare an outputSchema (clients receive validated structuredContent, not just text) and annotations (readOnlyHint, idempotentHint, openWorldHint — none are destructive).

Typical flow: search → pick a doc_id → get → answer & cite the html_url. When building an Extend app, reach for lookup_extend_reference first.

Requirements

Node 22+ — runs the TypeScript sources directly, no build step (verified on Node 25).
An MCP-capable client (Claude Code, Cursor, Claude Desktop, …).

Quick start

git clone https://github.com/philippesimard00/workday-docs-mcp.git
cd workday-docs-mcp
npm install
npm run build-index      # one-time, ~1 min: builds the Tier-2 full-text index (recommended)

Connect it to Claude Code (user scope = available in every project):

claude mcp add workday-docs --scope user -- node "$(pwd)/src/server.ts"
claude mcp list          # expect: workday-docs ✓ Connected

Or add it to any MCP client's config manually (use the absolute path to src/server.ts on your machine):

{
  "mcpServers": {
    "workday-docs": {
      "command": "node",
      "args": ["/absolute/path/to/workday-docs-mcp/src/server.ts"]
    }
  }
}

Skipping build-index still works — search just falls back to title-only matching. See Search modes.

The Extend builder skill

skills/workday-extend-builder/ is a Claude Code Skill that teaches the agent Workday Extend's mental model (declarative metadata + scripting, the real file types) and directs it to these tools — especially lookup_extend_reference — before it writes any code. This is what makes the "no prior experience" case work. Install it (per developer):

ln -s "$(pwd)/skills/workday-extend-builder" ~/.claude/skills/workday-extend-builder

See skills/README.md for details and the per-team customization section.

Search modes

search_workday_docs and lookup_extend_reference run in one of two modes; the response's engine field tells you which:

title (zero setup): matches page titles + breadcrumbs only. Fine for "find the page about X"; weak on how-to phrasing.
fulltext (after npm run build-index): BM25 over page bodies. Built for app-building — intent queries like "sortable grid with pagination" land on the right component. The index (~1,250 docs) is fetched once and cached at ~/.cache/workday-docs-mcp/; the server uses it automatically on next start. Re-run build-index to refresh.

How it works

The Workday developer site is a JavaScript single-page app, so the docs aren't readable by a normal fetch of a page URL. The content is served as markdown behind it, via two endpoints:

What	URL
Master table of contents	`https://developer.workday.com/doc/wcp_docs.yml`
Page markdown	`https://developer.workday.com/doc/<DOC_ID>.md`
Canonical human link	`https://developer.workday.com/wcp_docs/<DOC_ID>.html`

The server loads the TOC (cached 6h), serves page markdown (cached on disk), and — for full-text mode — builds a local BM25 index over every page body. All knowledge of these URLs is isolated in one file (src/workday-docs-adapter.ts), and a startup health check fails loudly if Workday changes the doc structure.

Project layout

src/
  types.ts                  Shared types (TocNode, IndexEntry, SearchHit)
  workday-docs-adapter.ts   The seam — the only file that knows Workday's URLs (TOC, page fetch, caching, health check)
  search.ts                 Tier-1 ranking (title/breadcrumb) — fallback
  fulltext.ts               Tier-2 BM25 inverted index over page bodies (pure JS, no native deps)
  build-index.ts            One-time builder for the Tier-2 index
  server.ts                 MCP wiring: 4 tools + stdio transport + boot health check
  smoke.ts                  Live end-to-end check, no MCP transport
  test-client.ts            Drives the tools over the real MCP protocol (stdio)
evals/                      12-question evaluation suite (verified) + how to run it
skills/                     workday-extend-builder Claude Code skill + install guide

Development

npm run typecheck    # tsc, no emit
npm run smoke        # hits the live endpoints: loads TOC, searches, fetches a page
npm run test-client  # drives all tools over the real MCP protocol (stdio)

evals/workday_docs_eval.xml is a 12-question suite (answers verified against live data) for measuring how well an LLM can answer real Workday questions with only these tools — useful as a regression/quality benchmark. See evals/README.md.

Notes & limitations

Unofficial. This project is not affiliated with or endorsed by Workday. It reads publicly available documentation pages.
Undocumented endpoints. wcp_docs.yml and /doc/*.md aren't a published API — Workday could change them. They're isolated in src/workday-docs-adapter.ts, and assertSchemaIntact() fails loudly at startup if the structure changes. Great for a dev-productivity tool; treat as a maintenance liability for anything critical.
Docs, not data. The server reads the documentation. It does not access any Workday tenant, customer data, or authenticated API.
Search quality depends on the index — build it (npm run build-index) for app-building. A future semantic (embeddings) tier would slot into the same search layer without changing the tools.

Available Tools

4 tools

browse_workday_tocBrowse the Workday docs table of contentsA

Read-onlyIdempotent

Explore the documentation hierarchy when keyword search misses.

Pass a breadcrumb path to expand a node; an empty path lists the top-level sections (Extend Apps, Integration Apps, Workday APIs, Workday Developer Copilot, ...). Use the returned doc_id values (non-null nodes are real pages) with get_workday_doc.

Args:

path (string[]): breadcrumb to expand, e.g. ['Extend Apps','Extend App Components Reference'] (default [])
depth (number): how many levels deep to expand, 1-3 (default 1)

Returns: { path, nodes: [{ title, doc_id, child_count, children? }] }

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Breadcrumb to expand, e.g. ['Extend Apps','Extend App Components Reference']
`depth`	No	Levels to expand (1-3)

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	Yes
`nodes`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds context on return structure (path, nodes with doc_id, child_count, children) and explains that non-null doc_ids indicate real pages, enhancing transparency beyond the annotations.

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 extremely concise: a brief opening sentence, then bulleted args and return format. Every sentence adds value, no redundancy. It front-loads the purpose and provides structured details efficiently.

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?

Given the output schema exists, the description appropriately summarizes return values. It covers the core use case and links to a sibling tool (get_workday_doc). It is complete for the tool's exploratory purpose, though it could mention limitations regarding deep nesting.

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?

Schema coverage is 100% (baseline 3). The description adds usage context: 'Pass a breadcrumb path to expand a node; an empty path lists the top-level sections' and clarifies depth range (1-3). This adds meaningful guidance beyond the schema's simple descriptions.

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 explicitly states the tool's purpose: exploring the documentation hierarchy when keyword search misses. It gives specific examples of top-level sections and explains how to use the returned doc_ids with get_workday_doc, clearly distinguishing its role from search.

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

Usage Guidelines4/5

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

The description advises using this tool when keyword search fails and directs using returned doc_ids with get_workday_doc. While it implies when not to use (when search works), it does not explicitly exclude alternatives like lookup_extend_reference.

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

get_workday_docGet a Workday doc pageA

Read-onlyIdempotent

Fetch the full markdown for one Workday documentation page.

Accepts EITHER a doc_id (from search_workday_docs) OR a developer.workday.com "/wcp_docs/.html" link. Always returns the canonical html_url so you can cite/link the page even if the body can't be fetched.

Args:

doc_id (string): a doc ID from search_workday_docs
html_url (string): alternatively, a developer.workday.com/wcp_docs/.html link

Returns: { doc_id, html_url, truncated, markdown, error? }

markdown: the page body (string), or null if the body fetch failed (see error)
truncated: true if the body exceeded 60000 chars and was cut
error: present only when the body could not be fetched (html_url is still valid to link)

ParametersJSON Schema

Name	Required	Description	Default
`doc_id`	No	Doc ID from search_workday_docs
`html_url`	No	A developer.workday.com/wcp_docs/<id>.html link

Output Schema

ParametersJSON Schema

Name	Required	Description
`doc_id`	Yes
`html_url`	Yes
`truncated`	Yes
`markdown`	Yes
`error`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations (readOnlyHint, idempotentHint, etc.) already indicate safety, but the description adds valuable behavioral details: truncation at 60k chars, error field only present on body fetch failure, and that html_url is always returned. This goes beyond annotations and provides a clear mental model of tool 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 remarkably concise: a single-sentence purpose followed by two short paragraphs covering usage and return format. Every sentence adds value, with no redundancy or filler. The structure is front-loaded and easy to scan.

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?

Given the tool's simplicity (two optional parameters, no nested objects, output schema provided), the description fully covers all aspects: input variants, edge cases (truncation, fetch failure), and output structure. No questions remain about how to use the tool or interpret results.

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?

Schema coverage is 100%, but the description adds meaningful context: explains that the parameters are mutually exclusive alternatives, specifies the source of doc_id ('from search_workday_docs'), and gives the exact URL format for html_url. This extra detail helps the agent understand how to choose and provide valid inputs.

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 clearly states the verb ('Fetch'), resource ('full markdown for one Workday documentation page'), and distinguishes from sibling tools like browse_workday_toc and search_workday_docs by specifying it retrieves a single page's content. The return fields are listed, leaving no ambiguity about the tool's purpose.

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

Usage Guidelines4/5

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

Explicitly says to use either doc_id or html_url, with clear sourcing from sibling tool search_workday_docs. It also notes that html_url is always returned for linking even if body fetch fails. While 'when not to use' is implicit (e.g., don't use for browsing or searching), the guidance is sufficient for an agent to correctly select and invoke the tool.

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

lookup_extend_referenceLook up an Extend component / function referenceA

Read-onlyIdempotent

Ground Extend app-building in the authoritative reference. Given what you're trying to build or use, this returns the BEST-matching reference page WITH its content inline (excerpt) — not just a pointer — plus alternative pointers. Use this before writing PMD/widget/scripting code so you ground on the real schema/signature instead of guessing.

Scoped to the "Extend App Components Reference" (PMD tags/widgets, model components, PMD functions, PMD scripting). For broader/conceptual docs use search_workday_docs. Best results require the full-text index (npm run build-index).

Args:

intent (string): what you want to build/use, e.g. "sortable grid with row actions", "function to format a date", "validate a field before submit"
kind ('any' | 'component' | 'function' | 'scripting'): narrow the scope (default 'any') component = PMD tags/widgets + model components; function = PMD functions; scripting = PMD scripting tags
alternatives (number): how many additional pointers to return, 0-10 (default 4)

Returns: { intent, kind, engine, best: { doc_id, title, breadcrumb, html_url, excerpt, truncated } | null, alternatives: [{ doc_id, title, breadcrumb, html_url, score }] } If best is null, nothing matched the scope — widen kind, rephrase, or use search_workday_docs.

ParametersJSON Schema

Name	Required	Description	Default
`intent`	Yes	What you want to build/use, e.g. 'sortable grid with row actions'
`kind`	No	Narrow scope: component \| function \| scripting \| any	any
`alternatives`	No	Number of additional pointers to return (0-10)

Output Schema

ParametersJSON Schema

Name	Required	Description
`intent`	Yes
`kind`	Yes
`engine`	Yes
`best`	Yes
`alternatives`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations provide readOnlyHint, idempotentHint, etc. Description adds value by explaining the tool returns excerpts inline, mentions the full-text index requirement, and describes the return structure, going beyond annotations.

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?

Description is front-loaded with purpose and usage, but contains some redundancy (e.g., repeats scope). However, every sentence is valuable and it remains clear. Minor room for conciseness improvement.

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?

Given the tool's complexity (3 params, output schema, annotations), the description covers purpose, usage, behavior, parameters, and return values completely. Output schema documents return structure, so no gaps.

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

Parameters5/5

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

Schema coverage is 100%, and the description enriches each parameter with examples (intent), detailed enum breakdown (kind), and explicit range/default (alternatives), adding meaning 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 clearly states it returns the best-matching reference page with inline content and alternative pointers, and distinguishes itself from siblings by scoping to the 'Extend App Components Reference' and directing broader queries to search_workday_docs.

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?

Explicitly advises using this tool before writing code to ground on real schema/signature, and specifies when to use search_workday_docs for broader/conceptual docs, providing clear usage context and alternatives.

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

search_workday_docsSearch Workday documentationA

Read-onlyIdempotent

Search the Workday developer documentation by concept, widget, API, or task.

Returns lightweight pointers (title, breadcrumb, doc_id, link) — NOT full page text. Call get_workday_doc with a returned doc_id to read a page.

When the full-text index is built (npm run build-index), this searches page BODIES (BM25), so intent/how-to phrasing works well — e.g. "sortable grid with pagination", "format a date in a PMD expression". Without the index it falls back to TITLE-only matching (engine="title"), where specific how-to phrasing may return weak hits — build the index for best results. The response 'engine' field tells you which mode ran.

Args:

query (string): concept/widget/API/task, e.g. "validate a field on submit"
section ('Extend Apps' | 'Integration Apps' | 'Workday APIs' | 'Workday Developer Copilot'): optional filter
limit (number): max results, 1-50 (default 10)

Returns: { query_echo, engine, count, results: [{ doc_id, title, breadcrumb, html_url, score }] } Higher score = stronger match. Empty results means no match — try broader terms or browse_workday_toc.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Concept/widget/API/task to find, e.g. 'validate a field on submit'
`section`	No	Restrict to a top-level section
`limit`	No	Max results (1-50)

Output Schema

ParametersJSON Schema

Name	Required	Description
`query_echo`	Yes
`engine`	Yes
`count`	Yes
`results`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already indicate read-only, non-destructive, idempotent. The description adds context: returns lightweight pointers, fallback to title-only matching, engine field in response, and empty results behavior. No contradictions.

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 detailed and well-structured, but slightly verbose. It front-loads purpose and usage, but could be trimmed without losing value.

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?

Given the tool's complexity and available schema/output schema, the description covers all aspects: behavior, parameters, return format, and integration with sibling tools. No gaps.

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?

Schema coverage is 100% with descriptions. The description adds examples for query and explains the effect of section and limit, but does not add new parameter info 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 clearly states it searches Workday documentation by concept, widget, API, or task. It distinguishes from siblings by specifying it returns lightweight pointers and directs to get_workday_doc for full text. Sibling browse_workday_toc is also mentioned.

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 explains when to use this tool for searching, when to use get_workday_doc instead, and how to improve results (build index). It also describes fallback behavior and how to interpret the response.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Jun 14, 2026
- First observedbrowse_workday_toc
- First observedget_workday_doc
- First observedlookup_extend_reference
- First observedsearch_workday_docs

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Disambiguation5/5

Each tool serves a distinct purpose: browsing hierarchy, fetching pages, searching general docs, and specialized reference lookup. No overlap in functionality.

Naming Consistency5/5

All tools use consistent snake_case with a verb_noun pattern (browse_, get_, lookup_, search_), making them predictable.

Tool Count5/5

Four tools are well-scoped for a documentation MCP: browsing, searching, fetching, and reference lookup. No excess or deficiency.

Completeness5/5

The set covers core documentation needs: exploration via TOC, full-text search, page retrieval, and targeted reference lookups. No obvious gaps.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ref-tools-ref-tools-mcpOAuth
ai.smithery
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Documentation Access Developer Tools Code Analysis
21,164
llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
developer-tools A
goog.workspace-developer
Provides tools for searching Google Workspace documentation and much more.
Developer Tools Documentation Access Search
22
@imqueue A
org.imqueue
Search @imqueue docs and scaffold typed services & clients from your AI coding agent.
Developer Tools Documentation Access
711

Related MCP Servers

Multi-Source Documentation MCP
Documentation Access Search
florinel-chis
A
license
Not graded
quality
D
maintenance
Enables AI assistants to search and query documentation from multiple sources including Voiceflow and Claude Code, with full-text search, code examples retrieval, and step-by-step tutorials access.
Updated 10 months ago (2025-11-12 18:20 UTC)
1
MIT
LangChain & LlamaIndex Coding
Documentation Access Developer Tools Search
aadhil96
F
license
Not graded
quality
D
maintenance
Provides real-time retrieval of official documentation for LangChain, LlamaIndex, and OpenAI. It enables context-aware coding by fetching the latest API references and guides directly into Claude via the Model Context Protocol.
Updated 9 months ago (2025-12-13 14:48 UTC)
-
MCP Server for Up-to-Date
Documentation Access AI & Machine Learning Developer Tools
AmirUpSkill
F
license
A
quality
D
maintenance
Provides Large Language Models with real-time access to the latest documentation for Python libraries like Langchain, LlamaIndex, and OpenAI, enabling accurate and up-to-date code suggestions.
Updated a year ago (2025-05-04 17:43 UTC)
1
-
doc-hub-mcp
Documentation Access Search
wxkingstar
F
license
Not graded
quality
C
maintenance
Provides retrieval of WeChat Work and Feishu developer documentation, enabling AI assistants to query API references without switching browsers.
Updated 6 months ago (2026-02-28 06:27 UTC)
18
19
-

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/philippesimard00/workday-docs-mcp'

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