building-standards-act-mcp

Server Quality Checklist

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

Latest release: v1.7.0
Disambiguation5/5
すべてのツールが明確に異なる目的を持ち、重複がありません。analyze_article、check_law_updates、get_full_lawなど、各ツールの役割が一意に定義されています。
Naming Consistency5/5
一貫してスネークケース、動詞＋名詞のパターン（例：analyze_article、get_full_law）が使用されており、命名規則は一貫しています。
Tool Count5/5
10個のツールは建築基準法というドメインに適切な数であり、必要な機能が過不足なく揃っています。
Completeness4/5
条文本体のキーワード検索ができない点など、わずかなギャップはあるが、全体として条文取得、更新確認、引用検証など主要なユースケースをカバーしています。
Average 3.8/5 across 10 of 10 tools scored. Lowest: 3.2/5.
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
- Last stable release on April 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool returns JSON metadata, implying a read-only operation, but does not explicitly confirm this or disclose any side effects, rate limits, or authentication needs. The description adds some transparency about the output nature but lacks full disclosure.
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 two sentences with no wasted words. It front-loads the main action (structural analysis and metadata return) and adds context (use as source for AI generation). It is appropriately sized for the tool's simplicity, though it could be slightly more precise about output details.
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 2 parameters, no nested objects, no output schema, and 100% schema coverage, the description is adequate but not complete. It mentions the output format (JSON) and lists example metadata fields, but does not specify the exact structure or any edge cases. Relative to the complexity, it meets a minimum viable standard.
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% because both law_name and article_number have descriptive examples in the schema. The description does not add new meaning beyond the schema, so the baseline score of 3 applies. No param-specific guidance is provided beyond what the schema already contains.
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 analyzes legal article structure and returns metadata like paragraph counts and reference statistics. It uses a specific verb-resource combination ('逐条の構造を解析し...メタデータを返す') and mentions the use case for AI summaries. However, it does not explicitly differentiate from sibling tools like get_law or search_law, which limits clarity for agent selection.
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 implies usage for structural analysis but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_law for full text, search_law for searching). No when-not-to-use or prerequisite conditions are mentioned, leaving the agent to infer the tool's niche without concrete direction.
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?
注釈が一切ないため、説明文が行動開示の全責任を負う。format=structuredでの階層構造JSON出力が可能であることを追加で説明しているが、エラー時や認証要件、レート制限などについての言及はなく、最小限の開示にとどまる。
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?
3文で必要十分な情報を提供しており、無駄がない。最初の文でツールの主要目的を明確に述べ、続けてスコープ（附則・別表対応）と指定方法（略称可）、特殊出力形式（structured）を簡潔に説明している。
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?
出力スキーマがなく、注釈もない状況で、説明文はツールの機能をある程度カバーしているが、返却されるデータの構造（text形式の場合）、エラーハンドリング、ページネーションなどの実用的な詳細が欠けており、完全とは言えない。
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?
入力スキーマのカバレッジは100%で、スキーマ自体がパラメータをよく説明している。説明文は、正式名称/略称の両方が指定可能であること、article_numberに附則・別表が使えること、formatの効果を補足しており、スキーマを超える価値を追加している。
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?
明確に、「条番号を指定して法令の条文を取得する」と記述されており、附則・別表への対応や略称使用も明示。 siblings（get_full_law, search_law等）との差別化はされていないが、目的は具体的で理解しやすい。
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?
どのような場合にこのツールを使うべきか、あるいは使うべきでないかについてのガイダンスがない。 siblingsとの比較や、代替手段の示唆がないため、エージェントが適切な選択をするための情報が不足している。
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions efficiency and max items but fails to disclose whether the operation is read-only, authorization needs, rate limits, or error behavior.
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?
Two sentences, front-loaded with main action, no superfluous text. Efficient and clear.
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?
With no output schema and no annotations, the description omits return value details, error handling, and potential side effects. For a batch tool, this leaves the agent uncertain about what the response contains.
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%, so parameters are already documented. The description adds context about batching but no additional semantic 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 the tool batches retrieval of multiple laws/articles, emphasizing efficiency for same-law articles and a max of 20 items. It distinguishes from siblings like get_law (single) and search_law (search).
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 use for batch retrieval but does not provide explicit guidance on when to use versus alternatives. No 'when not to use' or trade-offs are mentioned, though the batch context is clear.
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 only states the action without mentioning side effects, authentication needs, rate limits, or whether it is read-only. Describing 'suggest' may imply AI generation but is vague.
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 concise sentence that efficiently conveys the core functionality. All key information is front-loaded, and every word is necessary.
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 no output schema, the description should set expectations for the return format or range of suggestions. It mentions 'automatically extract and suggest' but lacks details on what the agent can expect from the response, making it moderately 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%, with both parameters having clear descriptions in the schema. The tool description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
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 specific action ('自動抽出して提案する' = automatically extract and suggest) and the resource (related laws, delegation destinations, internal references for a specified article). It effectively distinguishes this tool from siblings like get_law or search_law by focusing on cross-references.
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 for finding references from a specific article, but lacks explicit guidance on when to use vs. alternatives, when not to use, or prerequisites. No exclusions or comparisons to sibling tools are provided.
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?
The description discloses the two-step retrieval process (database then fallback API), but lacks detail on output format (e.g., PDF text), error handling, or limitations—especially important since no annotations exist.
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?
Two sentences efficiently convey purpose and method. No fluff, though the structure could separate purpose from process more cleanly.
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?
The description covers purpose and retrieval logic adequately for a simple tool, but omits the return format and any prerequisites (e.g., internet access), which could confuse an 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 single parameter is fully described in the schema (including examples), so the description adds no extra semantic value. Baseline 3 applies due to 100% schema coverage.
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 retrieves the full text of notifications (kokuji) delegated by the Building Standards Law, distinct from sibling tools that handle laws, articles, or searches.
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 the tool is for retrieving kokuji text, but does not explicitly indicate when to use it over alternatives like get_law or search_law, nor does it provide exclusions.
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 describes capabilities (existence check, text matching) and a limit of 10 items, but lacks details on side effects, authentication, or error handling. Transparency is moderate.
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 two short sentences in Japanese, front-loaded with the core action and capabilities. Every sentence adds value without redundancy.
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?
The description does not explain the output or return value of the verification, which is critical for an agent to interpret results. Nor does it mention prerequisites or error handling. Given no output schema, this is a significant gap.
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 already documents all parameters thoroughly. The tool description adds only the maxItems constraint, which is already present in the schema. Little added value beyond 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 the tool's purpose: verifying legal citations in AI responses, with existence check and text matching. It distinguishes from sibling tools like search_law or get_law which are for retrieval, not verification.
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 for verifying AI-generated legal citations but does not explicitly mention when not to use it or provide alternatives. The context is implied but not explicit.
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 states the action (get text) and scope (full law), which is adequate for a read-only operation. However, it does not disclose any additional behavioral traits like rate limits or authentication, though these are less critical for a simple retrieval.
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 two short sentences with no wasted words. It front-loads the purpose and is efficient.
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 simplicity of the tool (one parameter, no output schema, no annotations), the description is sufficient. It clearly communicates the tool's function and input. It could mention the output format or language, but it is not critically missing.
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%, so the input schema already fully describes the parameter 'law_name'. The description does not add extra meaning beyond what is in the schema, so a baseline of 3 is appropriate.
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 'get' and resource 'full law text'. It distinguishes from siblings by explicitly saying it returns the entire law without article numbers, which differentiates it from tools like 'get_law' or 'analyze_article'.
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 indicates when to use: when you need the full text without specifying article numbers. It implicitly suggests using other tools for article-level queries, but does not explicitly name alternatives or state when not to use.
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 exist, so the description bears full responsibility for behavioral disclosure. It states the tool returns metrics, implying a read operation, but does not mention possible side effects, permission requirements, or performance implications. The lack of parameters simplifies but still leaves gaps.
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 sentence that efficiently conveys the tool's purpose and included metrics. It is front-loaded with the action and resource, with zero wasted words.
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?
The description enumerates specific metrics returned, which is sufficient for a simple read-only tool with no parameters. However, without an output schema, some detail about the format or aggregation period could enhance completeness. Overall, it provides adequate context.
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 input schema has no parameters, and schema description coverage is 100% by default. With zero parameters, the description does not need to add parameter-level detail. Baseline score of 4 is appropriate.
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 tool returns server usage metrics, listing specific types (tool calls, API requests, cache hit rate, uptime). The verb '返す' (returns) indicates a read operation. The resource 'メトリクス' (metrics) is distinct from sibling tools which focus on law-related functions.
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 provides no guidance on when to use this tool over alternatives or any prerequisites. Usage is implied by the tool's purpose (getting server metrics), but there is no explicit context or exclusion list.
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?
The description mentions external API dependency and the three functionalities, but lacks details on error handling, rate limits, or behavior when law_name is missing. No annotations provided, so description carries full burden.
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?
Single, well-structured sentence with no wasted words; each clause adds essential information about a different mode.
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?
For a tool with 3 optional parameters and no output schema, the description covers the main behaviors and parameter interactions, though output format and error scenarios are not detailed.
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?
Parameter schema covers 100% with descriptions; tool description adds value by grouping parameters into usage modes and noting that show_history only works with law_name, clarifying relationships beyond 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 the tool checks law revision status via e-Gov API, and distinguishes three usage modes (single, batch, history), effectively differentiating from sibling tools.
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 provides clear context for when to use each mode (single check with law_name, batch with group, history with show_history), but does not explicitly exclude other uses or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses the tool's behavior: it searches only law names/titles, not article text, and uses both registered aliases and the e-Gov API. The limitation is clearly stated.
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?
Two sentences, front-loaded with purpose, immediate limitations, and alternatives. Every sentence is informative and necessary.
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 (search over multiple sources, sibling tools) and absence of output schema, the description provides sufficient context: domain (building laws), data sources, limitation, and referral to sibling tools. It is complete for an AI agent to decide when to use it.
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 schema provides a description of the 'keyword' parameter with examples. The tool description adds context about how the keyword is used (searches titles, both data sources) and explains the limitation. This adds value beyond the schema, though the schema already covers the parameter well.
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 cross-searches building-related laws by keyword, searching both aliases and e-Gov API. It distinguishes itself from siblings like get_law and get_full_law by specifying the search scope (title only) and providing alternatives.
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 states when not to use this tool (for article text search) and points to alternative tools (get_law, get_full_law), providing clear usage guidance.
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:

[![building-standards-act-mcp MCP server](https://glama.ai/mcp/servers/Sora-bluesky/building-standards-act-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Sora-bluesky/building-standards-act-mcp)

Score Badge

Copy to your README.md:

[![building-standards-act-mcp MCP server](https://glama.ai/mcp/servers/Sora-bluesky/building-standards-act-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Sora-bluesky/building-standards-act-mcp)

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/Sora-bluesky/building-standards-act-mcp'

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