Complete classical & world literature — search + cite exact passages, facing sources, 50+ languages.
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 3.5/5 across 19 of 19 tools scored. Lowest: 2.6/5.
Each tool targets a distinct aspect of the corpus: general search vs. specific entity search, passage retrieval vs. work metadata, allusions vs. cross-references, etc. No two tools appear to do the same thing.
All tool names follow a consistent verb_noun pattern (e.g., list_authors, search_corpus, get_passage) and use snake_case throughout, making the set predictable and easy to navigate.
With 19 tools, the server is slightly above the ideal 3-15 range, but each tool covers a necessary function for a rich text corpus API (search, retrieval, cross-referencing). No tools feel redundant or excessive.
The tool surface comprehensively covers the domain: listing authors/works, searching for passages/entities/Greek phrases/letters, retrieving full passages, work metadata, allusions, crossrefs, parallel texts, citation formatting, and AI evidence pack building. No obvious gaps are present.
build_source_packBuild Source PackABuild an evidence pack for an AI answer: source-linked passages, related entities, and citation instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | scholar | |
| limit | No | ||
| query | Yes | Question or topic to research. | |
| author | No | Optional author slug or name. | |
| category | No | Optional work category filter. |
| Name | Required | Description |
|---|---|---|
| mode | No | |
| query | No | |
| author | No | |
| passages | No | |
| instructions | No | |
| citation_policy | No | |
| related_entities | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it builds a pack (non-destructive) and lists components (passages, entities, citations), providing some behavioral context beyond the annotations, but not rich details.
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?
Single sentence that is concise and front-loaded with the core purpose. No wasted 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?
Given the existence of an output schema (not shown but indicated), the description need not detail return values. It covers the tool's high-level functionality adequately for a tool with moderate complexity and good annotations.
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 60%, but the description does not elaborate on parameters beyond what the schema provides. The description adds no additional meaning for query, mode, limit, author, or category, so it does not compensate for the coverage gap.
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's purpose: building an evidence pack with source-linked passages, related entities, and citation instructions. It distinguishes itself from siblings like cite_passage or get_passage by focusing on assembling multiple components.
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?
No guidance on when to use this tool vs alternatives. For example, if only a single passage is needed, get_passage might be more appropriate. The description lacks context about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cite_passageCite PassageCFormat a Hermitsh work or passage citation in common citation styles.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Optional Hermitsh work or passage URL. | |
| style | No | chicago-note | |
| author | No | Author slug or name. Optional if url is provided. | |
| work_id | No | Work ID. Optional if url is provided. | |
| section_id | No | Optional section or passage ID. |
| Name | Required | Description |
|---|---|---|
| url | No | |
| style | No | |
| title | No | |
| author | No | |
| work_id | No | |
| citation | No | |
| section_id | No | |
| access_date | No | |
| author_slug | No | |
| bibliography | No | |
| source_title | No | |
| metadata_used | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds no behavioral traits beyond that. It does not disclose edge cases, error handling, or limitations. With annotations covering safety, the description adds little value.
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 very short (one sentence, 10 words) and front-loaded with verb and object. It earns its place but could benefit from a bit more detail, such as mentioning the default style or output type.
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?
Despite having 5 parameters, an output schema, and annotations, the description lacks completeness. It does not explain how the tool resolves citations from URL versus author/work_id, nor does it mention the default style or output format (string). More context would help the agent use it correctly.
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 description coverage is 80%, so the schema already explains the parameters. The tool description does not add any additional meaning beyond what is in the schema. 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?
The description clearly states the tool formats a citation of a Hermitsh work or passage in common citation styles, with a specific verb and resource. It distinguishes from sibling tools (e.g., get_passage, get_work) which retrieve content, not format citations. However, it could explicitly list the styles or note that it generates a string.
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?
No usage guidance is provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites (e.g., needing at least a url or author+work_id). It simply states the function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_mentionsFind MentionsBReturn source-linked places where a person, place, event, work, institution, or concept is mentioned.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| author | Yes | ||
| entity | No | ||
| work_id | No | Optional work filter. | |
| entity_id | No |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | No | |
| entity | No | |
| mentions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read operation (readOnlyHint, destructiveHint false). Description adds 'source-linked' context but doesn't elaborate on behavioral aspects like result ordering, pagination, or what constitutes a 'mention'. No contradiction with annotations.
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?
Single sentence is highly concise with no extraneous words. Appropriately front-loaded with the core action.
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?
With 6 parameters, 1 required, and an output schema present, the description is too sparse. It omits crucial context like how parameters relate to each other, the meaning of 'source-linked', and how results are presented. Incomplete given tool complexity.
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 description coverage is only 17% (only work_id described). Description does not explain the roles of query, author, entity, entity_id, or limit. Users cannot determine how these parameters interact or which combination to use for a specific mention search.
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 clearly states the tool returns mentions of various entity types in sources, with a specific verb 'return' and resource 'source-linked places'. It distinguishes from sibling tools like search_corpus (general text search) or get_allusions (specific allusion type).
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?
No explicit guidance on when to use this tool versus alternatives like search_entities or get_crossrefs. Missing context about typical use cases or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_allusionsGet AllusionsAGet detected allusions, echoes, quotations, suspected sources, and translator notes for a work or section where available.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| author | Yes | ||
| work_id | Yes | ||
| section_id | No |
| Name | Required | Description |
|---|---|---|
| count | No | |
| title | No | |
| author | No | |
| work_id | No | |
| allusions | No | |
| author_slug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read-only behavior. The description adds that results are available 'where available', but does not disclose other behavioral traits like pagination or performance implications. The description provides minor additional context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that conveys the tool's purpose without superfluous words. It is front-loaded with the verb and key resource, making it efficient.
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 4 parameters, existing output schema, and annotations, the description is adequate but not fully complete. It lacks details on required parameters, pagination behavior, and when allusions may not be available. The output schema handles return value documentation, so the description's brevity is partially justified, but more context on usage would improve completeness.
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 description coverage is 0%, so the description must add meaning. It mentions 'work or section', which loosely explains work_id and section_id, but fails to clarify the required 'author' parameter or the pagination 'limit' parameter. The description does not compensate for the lack of parameter descriptions in 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 clearly states that the tool retrieves allusions, echoes, quotations, suspected sources, and translator notes for a work or section. It uses specific verbs ('Get detected') and resources ('allusions...') and is distinct from sibling tools like 'get_work' or 'get_passage'.
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 implies usage when needing allusion data for a work or section, but lacks explicit guidance on when to use this tool versus alternatives, such as 'search_corpus' or 'find_mentions', and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_author_personaGet Author PersonaAGet setup instructions for an AI assistant to answer as, about, or from the corpus of an author while using source-linked evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | voice | |
| author | Yes | Author slug or name, e.g. cicero. |
| Name | Required | Description |
|---|---|---|
| mode | No | |
| setup | No | |
| author | No | |
| persona | No | |
| warning | No | |
| author_slug | No | |
| tools_to_use | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that it returns 'setup instructions' with 'source-linked evidence', but does not disclose additional behavioral traits 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words, efficiently conveying the tool's purpose.
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?
While the tool has an output schema (not shown), the description does not elaborate on the return value format. With a simple purpose, the description is adequate but could benefit from mentioning that the output contains instructions and evidence sources.
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 50% parameter description coverage (only 'author' described). The description does not add meaning for the 'mode' parameter or clarify the 'author' parameter beyond the schema, failing to compensate for the low 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's action ('Get setup instructions') and resource ('for an AI assistant to answer as, about, or from the corpus of an author'), making it distinct from sibling tools like get_work or search_corpus.
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 implies usage context (for AI assistant persona setup) but provides no explicit guidance on when to use this tool versus alternatives, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crossrefsGet Cross-ReferencesAGet intra-corpus references and self-references for a work or section where available.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| author | Yes | ||
| work_id | Yes | ||
| section_id | No |
| Name | Required | Description |
|---|---|---|
| count | No | |
| title | No | |
| author | No | |
| work_id | No | |
| crossrefs | No | |
| author_slug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Description adds 'where available', hinting at conditional existence of references, but lacks details on pagination, error handling, or result behavior.
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?
Single sentence of 12 words, no redundancy. However, it omits parameter descriptions and could be slightly more structured without losing conciseness.
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 4 parameters (2 required) and an output schema (not shown), the description leaves gaps: no indication of return structure, how section_id qualifies the request, or what happens when cross-references are unavailable.
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 0%, so description carries full burden for parameter meaning, but it provides no explanations for any of the 4 parameters (author, work_id, limit, section_id). Parameter names offer limited semantics, but 'author' could be ambiguous.
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 clearly states verb 'get' and specific resource 'intra-corpus references and self-references for a work or section'. This distinguishes from siblings like 'find_mentions' or 'get_allusions' which likely target different types of references.
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?
Description implies scope ('intra-corpus, self-references') but does not explicitly state when to use this tool versus alternatives or provide prerequisites. No 'when-not' or sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entityGet EntityCGet a named entity and a sample of source-linked mentions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Entity query if the ID is unknown. | |
| author | Yes | ||
| entity | No | Entity name or alias if the ID is unknown. | |
| entity_id | No | Exact entity ID, e.g. person:caesar. | |
| mention_limit | No |
| Name | Required | Description |
|---|---|---|
| url | No | |
| note | No | |
| type | No | |
| title | No | |
| author | No | |
| aliases | No | |
| summary | No | |
| mentions | No | |
| entity_id | No | |
| categories | No | |
| author_slug | No | |
| short_title | No | |
| external_ids | No | |
| mention_count | No | |
| first_appearance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no additional behavioral context such as behavior on missing entities, response size, or error states. For a read-only tool, the description provides minimal extra transparency.
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 very concise (one sentence) and front-loaded. However, it may be too minimal, sacrificing completeness for brevity. Every sentence earns its place but more could be added.
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 5 parameters, many siblings, and a non-trivial output schema, the description is too sparse. It lacks details on how to specify the entity (ID vs query vs name), what the output includes beyond mentions, and how it differs from similar tools.
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 description coverage is 60%, with the required 'author' parameter lacking a description. The tool description does not explain any parameter semantics, leaving the agent to infer meaning from the schema alone. It fails to compensate for the schema gap.
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 retrieves a named entity and a sample of mentions. The verb 'get' and objects 'entity' and 'mentions' are specific. However, it does not distinguish from sibling tools like find_mentions or search_entities, which may overlap.
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?
No guidance on when to use this tool over alternatives (e.g., find_mentions, search_entities). No prerequisites, exclusions, or contextual hints provided. Usage is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_language_availabilityGet Language AvailabilityAShow source, active, deferred, and live edition status for one author or the whole Hermitsh library.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional filter such as source, active, deferred, live, coming_soon. | |
| author | No | Optional author slug or name. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| state | No | |
| author | No | |
| authors | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so description does not need to reiterate safety. Description adds no behavioral context beyond what annotations provide, which is acceptable but not exemplary.
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?
Single sentence with no redundancy. Clearly communicates purpose and scope without extraneous 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 simple tool with 2 optional params and existing output schema, description sufficiently covers what the tool does and its scope. No missing critical context.
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% for both parameters, so description adds minimal extra meaning. The description confirms the author parameter filters by author and state filters by status, but does not clarify format or valid values beyond 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?
Description uses specific verb 'Show' with clear resource 'edition status' and scope 'for one author or the whole Hermitsh library'. It distinguishes from sibling tools like list_authors or get_work which serve different purposes.
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?
Description states when to use: when edition status is needed for specific author or entire library. However, it does not explicitly mention when not to use or direct to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_parallel_passageGet Parallel PassageBGet aligned source-language text and English translation for a passage when sidecar data is available.
| Name | Required | Description | Default |
|---|---|---|---|
| author | Yes | ||
| work_id | Yes | ||
| section_id | Yes |
| Name | Required | Description |
|---|---|---|
| url | No | |
| date | No | |
| notes | No | |
| title | No | |
| author | No | |
| work_id | No | |
| category | No | |
| section_id | No | |
| author_slug | No | |
| data_source | No | |
| source_text | No | |
| translation | No | |
| source_title | No | |
| source_language | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and non-destructive behavior. The description adds the key constraint that sidecar data must be available, which is not covered by annotations. Some behavioral detail (e.g., no mention of error states) is missing.
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?
Single sentence, no wasted words. Front-loaded with purpose. However, lacks structural elements like bullet points or clear sectioning.
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?
Output schema exists (not shown) so return values are covered. Description explains what is returned. But no context on error handling, limitations, or when to use among many siblings. Adequate but not comprehensive.
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 0% description coverage and the tool description does not explain any of the three parameters (author, work_id, section_id). The agent must rely solely on parameter names, which is insufficient.
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 action ('Get'), the resource ('aligned source-language text and English translation'), and the condition ('when sidecar data is available'). It distinguishes from siblings like 'get_passage' by specifying parallel alignment.
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?
No explicit guidance on when to use this tool versus alternatives. The phrase 'when sidecar data is available' implies a prerequisite but doesn't compare to sibling tools like 'search_parallel' or 'get_passage'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_passageGet PassageBGet an exact passage by author, work ID, and section ID. Include the returned url as a link when using the passage.
| Name | Required | Description | Default |
|---|---|---|---|
| author | Yes | ||
| work_id | Yes | ||
| section_id | Yes |
| Name | Required | Description |
|---|---|---|
| url | No | |
| date | No | |
| text | No | |
| title | No | |
| author | No | |
| work_id | No | |
| category | No | |
| section_id | No | |
| author_slug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. However, the description adds minimal behavioral context beyond the instruction about the URL. No disclosure of rate limits, auth needs, or what happens if the passage is not found.
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?
Two concise sentences: the first clearly states the purpose, and the second gives a direct usage instruction. No unnecessary words; efficient and well-structured.
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 existence of an output schema, the description does not need to explain return values. However, it lacks context about domain specifics (e.g., classical texts) and prerequisites for using the identifiers. With many sibling tools, more guidance on tool selection would improve completeness.
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 description coverage is 0%, meaning the schema provides no parameter descriptions. The description names the three parameters (author, work_id, section_id) but gives no details about their format, valid values, or constraints. This is barely above baseline.
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 verb 'Get' and the resource 'passage', specifying the three identifiers (author, work_id, section_id) required for an exact retrieval. This differentiates it from sibling tools like get_work or get_parallel_passage.
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 provides a usage instruction ('Include the returned url as a link when using the passage'), but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_workGet WorkAGet metadata and opening passages for a specific work.
| Name | Required | Description | Default |
|---|---|---|---|
| author | Yes | ||
| work_id | Yes | ||
| max_passages | No |
| Name | Required | Description |
|---|---|---|
| url | No | |
| date | No | |
| note | No | |
| title | No | |
| author | No | |
| summary | No | |
| work_id | No | |
| category | No | |
| passages | No | |
| author_slug | No | |
| short_title | No | |
| passage_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds that it returns metadata and opening passages, which is consistent and provides additional context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that efficiently conveys the tool's purpose without any unnecessary words or repetition.
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 output schema covers return values, but the description lacks parameter explanations and usage guidance. For a tool with 3 parameters and many siblings, this is adequate but not fully complete.
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 description coverage is 0% and the description does not explain any parameters (author, work_id, max_passages). While the tool's purpose is clear, the agent receives no help understanding parameter meanings or constraints.
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 verb 'Get' and the resource 'work', specifying it returns 'metadata and opening passages'. This distinguishes it from sibling tools like get_passage or get_work_context, which have different scopes.
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?
No guidance on when to use this tool versus alternatives. With 17 sibling tools, the description should indicate when to choose get_work over others like get_passage or get_work_context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_work_contextGet Work ContextAGet richer work metadata: headnote, date context, source provenance, translation status, and edition links.
| Name | Required | Description | Default |
|---|---|---|---|
| author | Yes | ||
| work_id | Yes |
| Name | Required | Description |
|---|---|---|
| url | No | |
| date | No | |
| note | No | |
| title | No | |
| author | No | |
| titles | No | |
| summary | No | |
| work_id | No | |
| category | No | |
| headnote | No | |
| source_url | No | |
| author_slug | No | |
| short_title | No | |
| source_title | No | |
| translations | No | |
| edition_links | No | |
| passage_count | No | |
| date_precision | No | |
| date_range_end | No | |
| source_language | No | |
| location_written | No | |
| source_url_fallback | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safety. The description adds context on the nature of returned data (headnote, provenance, etc.), which is useful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with the action. It lists specific metadata elements, making it efficient. Could be slightly more structured but effective.
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 presence of an output schema, the description need not detail return values. It sufficiently summarizes the content type for a metadata retrieval tool. However, without usage guidance against siblings, completeness is slightly reduced.
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 0% and the description provides no information about the parameters (author, work_id) or their values. The description focuses solely on output, leaving parameter semantics entirely unspecified.
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 uses specific verb 'Get' and resource 'richer work metadata' with enumerated fields (headnote, date context, source provenance, etc.), clearly distinguishing it from sibling 'get_work' which presumably provides basic info.
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 phrase 'richer work metadata' implies a comparison to simpler alternatives like get_work, but there is no explicit guidance on when to use this tool versus siblings, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_authorsList AuthorsAList author corpora available through Hermitsh Texts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional author name or slug filter. |
| Name | Required | Description |
|---|---|---|
| schema | No | |
| authors | No | |
| generated_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds minor context about listing 'author corpora' but no additional behavioral details like pagination or response format.
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?
Single sentence with no fluff, but could be slightly more descriptive about the scope of the listing.
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 presence of an output schema, the description does not need to explain return values. It adequately describes the tool's purpose for a simple listing operation.
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%, so the schema already documents the optional query parameter. The description adds no new information beyond what the schema provides.
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 explicitly states the action (list), resource (author corpora), and source (Hermitsh Texts), clearly distinguishing it from siblings like list_works.
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?
No explicit guidance on when to use this tool vs alternatives, but the straightforward listing purpose implies usage for browsing available authors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_worksList WorksAList works by author, category, or title/summary query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Optional text filter for titles and summaries. | |
| author | No | Optional author slug or name, e.g. cicero, seneca. | |
| category | No | Optional category, e.g. philosophy, speeches, letters, poetry, history. |
| Name | Required | Description |
|---|---|---|
| works | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so description adds little behavioral context beyond 'List works'. Does not mention pagination (limit parameter) or behavior when no filters applied. No contradiction.
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?
Single efficient sentence with no wasted words. Front-loaded with verb+resource.
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?
With output schema present, description need not explain return values. Adequately covers core functionality for a simple listing tool; could optionally mention limit default but schema handles it.
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 covers 3 of 4 parameters (75%) with descriptions. Description groups parameters ('by author, category, or title/summary query') but does not add new meaning beyond schema. Baseline 3 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 clearly states the tool lists works and can filter by author, category, or title/summary query. It distinguishes from siblings like get_work (single work) and search_corpus (full-text search).
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?
Description implies usage for filtering works but does not explicitly state when not to use it or compare to alternatives like get_work or search_corpus. 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.
search_corpusSearch CorpusASearch passages across one author or the whole Hermitsh corpus and return source-linked results. Each result carries a url — include it as a link when quoting the passage.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Search query, such as tyranny, grief, friendship, debt, Caesar. | |
| author | No | Optional author slug or name. Strongly recommended for persona work. | |
| category | No | Optional category filter. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | No | |
| query | No | |
| author | No | |
| results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value beyond these by noting that each result carries a url and instructing to include it as a link when quoting, which is behavioral context not covered by annotations.
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?
Two sentences with no superfluous words. The first sentence defines the purpose, and the second adds a crucial usage note about result links. Every sentence earns its place.
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 presence of an output schema (which likely documents return fields), the description suffices for a search tool. It mentions url linking but could improve by briefly indicating free-text search capability and how author/category filters relate to the corpus scope. Still, it is fairly complete for the context.
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?
With 75% schema description coverage, the schema already documents most parameters adequately. The description does not add additional parameter-level details beyond what is in the schema, so it meets the baseline of 3 without exceeding.
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 'Search passages across one author or the whole Hermitsh corpus and return source-linked results,' specifying the verb (search), resource (passages/corpus), and scope (by author or entire corpus). This distinguishes it from sibling tools like search_greek_phrases and search_letters.
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 provides no guidance on when to use this tool versus alternatives. While it hints at result usage (include url as link), it lacks explicit when-to-use or when-not-to-use comparisons with siblings like search_parallel or get_passage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_entitiesSearch EntitiesBSearch people, places, events, institutions, works, and concepts extracted from an author corpus.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional entity type filter, e.g. person, place, event. | |
| limit | No | ||
| query | Yes | Entity name, alias, type, or concept to search for. | |
| author | No | Optional author slug or name. |
| Name | Required | Description |
|---|---|---|
| count | No | |
| query | No | |
| author | No | |
| entities | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, making it clear this is a safe read operation. The description adds no extra behavioral context beyond the schema, such as pagination, fuzzy search behavior, or rate limits, but does not contradict annotations.
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 a single sentence that is concise and front-loaded with the core purpose. No waste.
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 description is minimal but sufficient for a simple search tool given the output schema exists. However, it lacks details on search behavior (e.g., fuzzy matching, case sensitivity) and does not describe the output beyond entity types.
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 covers 75% of parameters with descriptions, so the schema does most of the work. The description adds no additional meaning for parameters beyond hinting at the 'type' filter via the entity list. 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?
The description uses a clear verb 'Search' and specifies the resource types (people, places, events, etc.) extracted from author corpus. It differentiates from sibling tools like search_corpus or search_letters by focusing on named entities, though it could be more explicit about what constitutes an entity.
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?
No guidance is provided on when to use this tool vs. alternatives such as get_entity for a single entity or search_corpus for broader text search. There is no mention of prerequisites, exclusions, or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_greek_phrasesSearch Greek PhrasesASearch catalogued Greek phrases, glosses, suspected sources, register, and source-certainty metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Optional search over Greek text, transliteration, gloss, context, source, or notes. | |
| author | No | Optional author slug or name. | |
| work_id | No | ||
| register | No | ||
| source_certainty | No |
| Name | Required | Description |
|---|---|---|
| count | No | |
| query | No | |
| author | No | |
| phrases | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool searches catalogued data, which is consistent with read-only behavior. However, no additional behavioral traits (e.g., pagination, ordering) are disclosed 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with essential information front-loaded ('Search catalogued Greek phrases'). Every word adds value; no redundancy or extra content.
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?
With 6 parameters (including an enum), the description is minimal but adequate given the presence of an output schema and annotations. It covers the general scope but omits details on optionality, defaults, or filtering behavior beyond the brief mention.
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 description coverage is 33% (only query and author have descriptions). The description compensates by listing searchable fields ('Greek text, transliteration, gloss, context, source, or notes') and mentioning register and source-certainty as metadata. However, it does not explain parameters like limit, work_id, or their interactions.
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 explicitly states 'Search catalogued Greek phrases, glosses, suspected sources, register, and source-certainty metadata.' It clearly identifies the verb (search) and the resource (Greek phrases with metadata), distinguishing it from siblings like search_corpus or search_entities which target different data.
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 implies usage for searching Greek phrases with specific metadata, but it does not provide explicit guidance on when to use this tool versus alternatives like search_corpus or search_letters. No when-not-to-use or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_lettersSearch LettersASearch correspondence metadata by correspondent, place, topic, mood, date range, or Greek usage where available.
| Name | Required | Description | Default |
|---|---|---|---|
| mood | No | ||
| limit | No | ||
| place | No | ||
| query | No | Optional general query over correspondent, place, topics, and mood. | |
| author | No | Optional author slug or name. Cicero and Pliny currently have the richest letter data. | |
| end_date | No | Optional ISO-ish upper bound. | |
| start_date | No | Optional ISO-ish lower bound, e.g. -0050-01-01. | |
| carries_greek | No | ||
| correspondent | No |
| Name | Required | Description |
|---|---|---|
| count | No | |
| query | No | |
| author | No | |
| letters | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by clarifying the tool searches 'correspondence metadata' (not full text), which is not obvious from the name alone. This is valuable, though no details on pagination or performance are given.
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?
A single, front-loaded sentence that conveys the essential function with no extraneous words. Every element earns its place.
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 9 optional parameters and an existing output schema, the description covers the main filtering dimensions but lacks details on query behavior (e.g., how 'query' interacts with other fields) or result interpretation. It is adequate but not thorough.
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?
With only 44% schema description coverage, the description compensates by listing searchable fields (correspondent, place, topic, mood, date range, Greek usage). However, it does not mention the 'limit' parameter or describe how multiple filters combine.
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 searches correspondence metadata with explicit filtering dimensions (correspondent, place, topic, mood, date range, Greek usage). This distinguishes it from sibling tools like search_corpus (full text) or search_greek_phrases (specific phrase search).
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 implies use for searching letter metadata but does not explicitly state when to prefer this over alternatives like search_corpus or search_entities. No when-not-to-use or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_parallelSearch Parallel TextBSearch aligned source-language and English translation sidecars across the corpus.
| Name | Required | Description | Default |
|---|---|---|---|
| field | No | both | |
| limit | No | ||
| query | Yes | ||
| author | No | Optional author slug or name. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | No | |
| field | No | |
| query | No | |
| author | No | |
| results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral details (e.g., pagination, performance, required permissions), but it does not contradict annotations.
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?
Single sentence, no fluff. Every word is necessary.
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?
While output schema exists (not shown), the description lacks context on how the search behaves (e.g., exact match, fuzzy), what 'sidecars' are, and how to effectively use the parameters. Minimal for a search tool with 4 parameters.
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 description coverage is low (25%, only author has a description). The description provides no additional parameter details. For a low-coverage schema, the description should compensate but does not.
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 it searches aligned source-language and English translation sidecars across the corpus. It specifies the resource and action, but 'sidecars' is jargon and could be clearer. It doesn't explicitly distinguish from siblings like search_corpus.
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?
No guidance on when to use this tool versus alternatives such as search_corpus or search_greek_phrases. The description does not mention prerequisites or contexts.
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!