Canonical vocabulary server for autonomous business design. Exposes the Arco Lexicon as seven MCP tools: term lookup, related terms, alignment verification, citation formatting, source retrieval, term listing, and term suggestion. No authentication required. Streamable HTTP transport.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 7 of 7 tools scored.
Each tool targets a distinct operation: citation, relationship graph, sources, listing, lookup, text scanning, and alignment scoring. Even overlapping tools like suggest_terms and verify_alignment are clearly differentiated by their output (term lists vs. scored report). No ambiguity remains after reading descriptions.
All seven tool names follow the same verb_noun pattern (e.g., cite_term, list_terms, verify_alignment) with consistent lowercase and underscores. The naming is uniform and predictable, making it easy to guess tool functionality.
Seven tools is well-scoped for a lexicon service, covering discovery, retrieval, relationships, sources, citations, and text analysis. Each tool earns its place without redundancy or bloat.
The tool surface fully covers the lexicon domain: listing, precise lookup, relationships, source gathering, citation formatting, and text alignment analysis. There are no obvious dead ends or missing lifecycle operations for a read-only lexicon API.
cite_termAInspectReturns citation-ready references for a Lexicon term in Chicago, MLA, and BibTeX formats. Access dates are injected at call time — never hardcoded. Read-only. Use this when producing academic papers, blog posts, or any content that requires a formatted reference to an Arco term. Use get_sources instead when you need a list of reading references rather than a formatted citation.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The Lexicon term to cite. Accepts canonical name or slug. | |
| context | Yes | The publication context for the citation — for example "academic paper", "blog post", or "investor memo". Used to tailor the citation format where applicable. |
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 'Read-only' and adds a behavioral nuance: 'Access dates are injected at call time — never hardcoded.' This goes beyond the function name and covers safety expectations. It doesn't describe error behavior or return structure, but for a simple citation tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: main function, a key behavioral note, and usage guidance with alternative. No fluff or repetition. Front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 required params, no output schema, no annotations), the description covers purpose, usage, alternative, and safety. It doesn't explicitly state whether all three citation formats are returned together or how errors are handled, but the guidance is sufficient for an agent to invoke it correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'term' and 'context' are described in the schema. The description adds no new parameter-level details beyond what the schema provides. It mentions 'Arco term' but doesn't clarify parameter syntax. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns citation-ready references for a Lexicon term in Chicago, MLA, and BibTeX formats.' It distinguishes itself from siblings by naming the alternative 'get_sources' for a different need (list of reading references vs formatted citation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this when producing academic papers, blog posts, or any content that requires a formatted reference to an Arco term.' It also provides a clear alternative: 'Use get_sources instead when you need a list of reading references rather than a formatted citation.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sourcesAInspectReturns all published Arco sources for a term — Lexicon entries, blog articles, wiki pages, and podcast episodes — ordered by recommended reading sequence. Read-only. Use this when you need a reading list or reference list for a term. Use cite_term instead when you need a formatted citation for a specific publication type.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The Lexicon term whose sources to retrieve. Accepts canonical name or slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states 'Read-only,' discloses the ordering ('ordered by recommended reading sequence'), and restricts to 'published' sources. It doesn't detail error handling or edge cases, but for a read-only list retrieval, this is sufficient. Slightly more detail on empty results or invalid terms would push to a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core functionality and scope, the second adds the read-only nature and usage context, and the third names the alternative tool. Every sentence carries essential information without redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, and no annotations, the description covers all necessary context: what sources are returned, their ordering, that it's read-only, when to use it, and when to use the alternative. The tool is simple enough that this is complete for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter coverage with a clear description of the `term` parameter, including that it accepts canonical name or slug. The tool description does not add extra parameter-level semantics beyond that, so the baseline of 3 is appropriate given the schema already fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all published Arco sources for a term, listing specific source types (Lexicon entries, blog articles, wiki pages, podcast episodes) and notes the ordering by recommended reading sequence. It also distinguishes itself from the sibling tool cite_term, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use this tool: 'Use this when you need a reading list or reference list for a term.' It also provides a clear alternative: 'Use cite_term instead when you need a formatted citation for a specific publication type.' This gives the agent both positive and negative usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_termsAInspectReturns all published Arco Lexicon terms grouped by pillar, each with its slug and canonical short definition. Accepts an optional pillar filter. Use this tool first when you do not know which term to look up — it gives you the full vocabulary to orient from. Use lookup_term once you have identified the term you need.
| Name | Required | Description | Default |
|---|---|---|---|
| pillar | No | Filter results to a single pillar. Valid values: "How We Think", "What We Observe", "What We've Learned". Omit to return all pillars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses the return contents (terms grouped by pillar, each with slug and definition) and the optional pillar filter, which is sufficient for a simple read-only listing operation. However, it does not explicitly state that it is read-only or describe potential errors, so a small gap remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding distinct value: what the tool returns, when to use it, and when to use the alternative. It is front-loaded and contains no redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is complete. It covers return values, grouping, optional filtering, and usage context relative to sibling tools, allowing the agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description of the pillar parameter, including valid values and that omitting it returns all pillars. The description only says 'Accepts an optional pillar filter,' which adds no new semantic meaning beyond the schema. Baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all published Arco Lexicon terms grouped by pillar, including slug and canonical short definition. It also differentiates from lookup_term by indicating when each should be used, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use this tool first when you do not know which term to look up' and 'Use lookup_term once you have identified the term you need.' This clearly tells the agent when to use this tool versus a specific alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_termAInspectReturns the canonical Arco definition, related terms, and source URL for any Lexicon term. Supports fuzzy matching — "autonomous company" resolves to "Autonomous Business". Use this tool when you need a precise definition. Use suggest_terms instead when you have a block of text and want to discover which terms apply.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The Lexicon term to look up. Accepts the canonical name, a slug, or a close variant. Fuzzy matching handles minor spelling differences and common synonyms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses fuzzy matching behavior with a concrete example and lists the return components (definition, related terms, source URL), giving a good sense of what to expect. It doesn't cover error handling or format, but for a simple read operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the core functionality, followed by an illustrative example and usage guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides enough information to understand purpose, usage, and return content. It names the returned elements and gives a clear usage direction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the term parameter (100% coverage), including acceptance of canonical names, slugs, and close variants. The description adds an example but no additional semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and names the exact resources ('canonical Arco definition, related terms, and source URL') for any Lexicon term. It also differentiates from the sibling suggest_terms by contrasting use cases, making it clear which tool this is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('when you need a precise definition') and directs to suggest_terms for a block-of-text use case. This provides clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_termsAInspectScans a block of text against all published Arco Lexicon terms using deterministic string matching — no LLM calls. Returns two lists: terms whose canonical names appear explicitly in the text (detected), and terms whose concepts are present but whose canonical names are absent (suggested). Maximum 10,000 characters. Use this to audit an article or passage for correct and complete Arco terminology. Use verify_alignment instead when you want a scored alignment report rather than a term discovery list.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The article or text block to scan. Plain text or markdown. Maximum 10,000 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: deterministic string matching, no LLM calls, two output lists (detected/suggested), and a 10,000 character limit. This goes beyond basic operation to explain confidently how it works and what to expect, leaving no major unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences: first defines the operation, second details output, third provides usage context and alternative. No redundant filler; every sentence adds new information and the description stays readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations or output schema, this description is complete: it explains the process, constraints, output content, and when to use vs. avoid it. The only minor omission is an exact structured return format, but the free-text description of two lists is sufficient for an agent, especially given no formal output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a well-described 'text' parameter. The description only reiterates the character limit ('Maximum 10,000 characters') already in the schema, adding no new parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Scans a block of text against all published Arco Lexicon terms') and resource. It clearly differentiates from sibling tools by explicitly noting when to use verify_alignment instead, and the distinct output structure (detected vs. suggested terms) separates it from lookup/list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case: 'Use this to audit an article or passage for correct and complete Arco terminology.' Also names an alternative tool (verify_alignment) and contrasts its purpose ('scored alignment report' vs. 'term discovery list'), giving clear when-to/not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_alignmentAInspectAnalyses a block of text against the Arco Lexicon using deterministic scoring — no LLM calls. Returns a structured alignment report with a per-term verdict (ALIGNED, PARTIALLY_ALIGNED, NEEDS_CLARIFICATION, MISALIGNED, or NO_ARCO_TERMS_DETECTED), an alignment score, a suggested reframe, and recommended reading. Maximum 5,000 characters. Use this to score and audit text for correct Arco terminology. Use suggest_terms instead when you want to discover which terms apply to a text without scoring it.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to analyse. Plain text or markdown. Maximum 5,000 characters. Trim or chunk longer inputs before calling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses deterministic scoring (no LLM calls), the exact structure of the report, and the character limit. This provides clear behavioral expectations without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, and every sentence adds value: what it does, what it returns, and when to use an alternative. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations), and the description fully covers its purpose, output, constraints, and usage context, including an alternative. The absence of an output schema is compensated by explicitly listing the report components.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single 'text' parameter, describing its type, maximum length, and preprocessing advice. The description only repeats the max length and adds context about the analysis purpose. Baseline 3 is appropriate since the schema already documents the parameter comprehensively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes text against the Arco Lexicon using deterministic scoring, with a specific output format and a distinguishing note about suggest_terms. It uses a specific verb and resource, and differentiates from its sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this to score and audit text for correct Arco terminology' and provides a direct alternative: 'Use suggest_terms instead when you want to discover which terms apply.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
