SpecProof: Search standards specs with MCP-ready precision.
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.1/5 across 17 of 17 tools scored. Lowest: 3.1/5.
Tools are largely distinct but there are clusters of similar functionality, such as multiple search mechanisms (search_specifications, semantic_search, get_requirements with a search parameter) and reference-graph tools (get_spec_references, get_spec_dependents, get_relationship_graph). Descriptions do differentiate them, but an agent could still be uncertain which to use for a given query.
Most tool names follow a snake_case verb_noun pattern (e.g., list_documents, search_specifications, get_requirements). However, semantic_search is adjective_noun rather than verb_noun, and get_database_stats is a generic outlier among the spec-focused tools. Overall the pattern is consistent with minor deviations.
With 17 tools, the set is slightly above the ideal 3-15 range but not excessive for the breadth of functionality: search, metadata, requirements, test generation, relationships, and schemas. Each tool has a defined role, and the count feels warranted for the domain.
The tool set covers the core workflow well: discovering specs (search_specifications, list_documents), retrieving content (get_document_content, get_requirements), analyzing relationships (get_spec_references, get_spec_dependents), and generating tests (build_cross_spec_suite, generate_tests). Minor gaps exist, such as the lack of a direct tool to fetch a requirement's full surrounding clause (workaround via get_document_content), but no critical dead ends.
build_cross_spec_suiteBuild Cross-Spec SuiteAAssemble the normative requirements for one procedure across a spec AND the specs it normatively references — a procedure like registration or handover is never described in a single document. Returns a cited suite plan; feed the requirement_ids to generate_tests.
Args:
spec_base: The anchor spec, e.g. "23502" or "38331"
keyword: The procedure/topic, e.g. "registration", "handover", "authentication"
include_references: Also pull matching clauses from specs this one references (default: True)
limit: Max requirements in the plan (default: 20, max: 50)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| keyword | Yes | ||
| spec_base | Yes | ||
| include_references | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by stating it returns a 'cited suite plan' and explaining the include_references default. It does not contradict annotations. Could mention more about error cases, but the output schema likely covers return 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?
The description is tightly structured: a two-sentence overview explaining purpose and output, followed by a compact parameter list. Every sentence adds value, and there is no unnecessary repetition or fluff.
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 complexity, the description covers purpose, return value, parameter semantics, and the connection to generate_tests. With annotations and an output schema present, it doesn't need to detail every edge case. Minor gaps like handling no-matching results, but overall quite 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%, so the description's Args section carries all parameter meaning. It explains all 4 parameters with examples (spec_base, keyword), defaults (include_references, limit), and constraints (max: 50). This goes well beyond the bare schema titles.
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 function: 'Assemble the normative requirements for one procedure across a spec AND the specs it normatively references.' It uses specific verbs and identifies the resource, and the cross-spec scope distinguishes it from siblings like get_requirements and get_spec_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?
It explains the rationale for using this tool ('a procedure like registration or handover is never described in a single document') and gives downstream guidance ('feed the requirement_ids to generate_tests'). However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
diff_spec_versionsDiff Spec VersionsADiff two versions of a specification at the NORMATIVE level: which requirements were added, removed, or reworded. Not a textual diff — a clause that merely moved page or was recased counts as unchanged.
Args:
spec_base: Spec identity without the version, e.g. "38331" or "23501"
from_version: Older version label, e.g. "j20" (default: the second-newest in the corpus)
to_version: Newer version label, e.g. "j30" (default: the newest in the corpus)
obligation: Only report changes at this strength — "must", "must_not", "should", "should_not", "may"
limit: Max requirements to list per bucket (default: 25)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| spec_base | Yes | ||
| obligation | No | ||
| to_version | No | ||
| from_version | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds meaningful semantics: the diff operates at a normative level (ignoring page moves/casing) and applies default version selection, which the agent could not infer from annotations alone.
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 two short paragraphs: a clear behavioral summary followed by a compact Args block. Every sentence adds information without redundancy, making it highly 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 tool's complexity and a present output schema, the description adequately explains the core behavior, parameter semantics, and version defaults. Minor omissions like defining 'buckets' are covered by the output schema and overall 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 descriptions are completely absent (0% coverage), so the description carries full responsibility. It defines every parameter with examples (spec_base), allowed values (obligation), and defaults (from_version, to_version, limit), exceeding 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 states a specific verb ('Diff') and resource ('two versions of a specification') at the NORMATIVE level, listing exactly what changes are reported (added, removed, reworded). It further distinguishes itself from a textual diff, making the 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 clarifies it is not a textual diff and defines what counts as unchanged, giving when-not guidance. It also explains defaults for from_version/to_version. However, it does not explicitly name alternative sibling tools, so it falls short of full alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_testsGenerate Conformance TestsAGenerate a cited, runnable conformance test that verifies one normative requirement.
The test is grounded in the requirement sentence plus its surrounding clause from the
corpus, and every test cites the spec, section and page it enforces. If the requirement
is not testable (boilerplate, scope text), the generator abstains rather than inventing
a test.
Args:
requirement_id: The requirement's id, as shown by get_requirements
target: "pytest" for a runnable Python test module, or "gherkin" for a reviewable
.feature file (default: pytest)
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | pytest | |
| requirement_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: the test is grounded in the requirement sentence and clause, cites spec/section/page, and the generator abstains rather than inventing tests. This goes beyond annotations though it does not detail failure modes or return values, which are covered by the output schema.
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 front-loaded with the core purpose, followed by a concise behavioral paragraph and clear Args documentation. Every sentence adds value without redundancy or fluff.
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 tool with 2 parameters and an existing output schema, the description covers input semantics, the abstention behavior, citation grounding, and target choices. It is complete enough for an agent to select and invoke the tool 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 coverage is 0%, but the description fully compensates by explaining requirement_id as the id shown by get_requirements and target as 'pytest' for a runnable module or 'gherkin' for a reviewable .feature file with default pytest. This adds substantial meaning beyond the raw 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 the tool 'generates a cited, runnable conformance test' for 'one normative requirement', identifying the specific verb and resource. It distinguishes itself from siblings by referencing requirement_id from get_requirements and offering distinct target formats (pytest/gherkin).
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?
Clear usage context is provided: the requirement_id is sourced from get_requirements, and the target parameter selects between pytest and gherkin. It also describes abstention behavior for untestable requirements, but does not explicitly contrast with alternative sibling tools or state 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_database_statsDatabase StatisticsBGet comprehensive database and system statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context such as scope, rate limits, or what system components are covered, providing minimal value beyond the structured fields.
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 front-loads the action and resource. It is concise and avoids redundancy, though it could include more useful detail without becoming verbose.
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 no parameters, an output schema, and clear annotations, a simple description is mostly sufficient. However, 'comprehensive database and system statistics' is vague and could be interpreted in many ways, and there is no usage context provided, leaving some ambiguity.
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 tool has zero parameters, and schema description coverage is 100% vacuously. According to the rubric, 0 parameters warrants a baseline of 4. The description does not need to explain parameters since there are none.
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 the verb 'Get' and identifies the resource as 'database and system statistics,' which is clear and distinct from sibling tools that focus on spec documents. However, it lacks specificity about what statistics are included, so it does not fully meet the highest bar.
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. It simply states its purpose without any contextual cues or comparison to sibling tools, leaving the agent without explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_document_contentGet Document ContentAGet specific content from a specification document.
Args:
filename: Document filename (required)
page_range: Page range like "10-15" or single page "20" (optional)
section: Section title filter (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | ||
| filename | Yes | ||
| page_range | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds filter semantics (page_range, section) but does not disclose return format, error behavior, or limitations beyond schema. With annotations present, this is acceptable but not rich.
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 concise lines, front-loaded with the tool's purpose, and every sentence earns its place. The parameter list is clearly formatted and easy to scan.
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 simple retrieval tool with 3 straightforward parameters and an output schema, the description covers the essential usage. It lacks guidance on when to choose this tool over siblings and does not mention edge cases, but overall it is adequately complete for its 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 coverage is 0%, but the description fully compensates by explaining each parameter: filename is required, page_range accepts '10-15' or '20' formats, and section acts as a title filter. This adds meaning beyond the raw schema types.
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 states a specific action ('Get specific content') on a specific resource ('specification document') with clear filtering options. It does not explicitly differentiate from sibling tools, but the name and description make its function clear enough.
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 versus alternatives like get_requirements or get_schema_definitions. There is no mention of use cases, exclusions, or when the page_range/section filters are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_most_referenced_specsAInspectGet the most referenced (most important) specifications ranked by incoming reference count.
Args:
doc_type: Filter by "3gpp" or "ietf"
series: Filter by series number
limit: Maximum results (default: 20)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| series | No | ||
| doc_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains the core query behavior and parameters but does not disclose additional details such as data source, sorting order, or side effects. It is clearly a read operation, but deeper behavioral context 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?
The description is concise, front-loaded with the main purpose, and uses a structured Args list for parameters. Every sentence adds value with no redundancy.
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 an output schema present and a straightforward aggregation tool, the description covers the essential purpose and parameters. It could explicitly state that results are in descending order by reference count, but 'ranked' implies this. Overall complete for the tool's 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 0%, but the description compensates by explaining each parameter: doc_type filters to '3gpp' or 'ietf', series filters by series number, and limit sets maximum results with a default of 20. This adds meaningful semantics beyond the bare 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 specifies the action ('Get'), the resource ('most referenced specifications'), and the ranking criterion ('by incoming reference count'). It distinguishes from siblings like get_spec_references by focusing on aggregate ranking rather than references for a single spec.
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 clear context on how to use the tool, including optional filters (doc_type, series, limit). However, it does not explicitly mention when to choose this over siblings or any exclusion conditions, so it lacks full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_relationship_graphAInspectGet a relationship graph centered on a specification, expanding N hops.
Returns JSON with nodes and edges suitable for graph visualization.
Each node includes title, series, working group, and reference counts.
Each edge includes source, target, reference type, and count.
Args:
spec_number: Center specification number
depth: Number of hops to expand (1-3, default: 1)
reference_type: Filter by type - "normative", "informative" (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | ||
| spec_number | Yes | ||
| reference_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explains the exact returned graph structure (nodes with title, series, working group, reference counts; edges with source, target, reference type, count) and parameter constraints (depth 1-3, optional reference_type). It does not mention error cases or rate limits, but the read-only nature is evident from 'Get' and 'Returns JSON'.
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 (around 120 words), front-loaded with a clear one-sentence purpose, then structured return details and Args. Each line adds useful information without repetition or filler.
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 has 3 parameters and an output schema, and the description covers parameter semantics and return fields. However, it does not provide usage context relative to sibling tools or mention potential edge cases (e.g., missing spec_number, depth limit behavior). This is a minor gap, so not a perfect 5.
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 JSON schema only provides types and defaults, so schema description coverage is 0%. The description's Args section adds full semantics: spec_number as center, depth as number of hops with valid range/default, reference_type as filter with allowed values. This fully compensates 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 opens with a specific verb and resource: 'Get a relationship graph centered on a specification, expanding N hops.' It clarifies the graph traversal nature and distinguishes it from sibling tools like get_spec_references or get_spec_dependents by highlighting multi-hop expansion and node/edge output.
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?
There is no explicit comparison to alternatives or exclusions. The phrase 'expanding N hops' implies use for relationship graph exploration rather than direct reference lookup, but the description does not state when to prefer this tool over get_spec_references or get_rfc_lineage. This is implied usage, not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_requirementsGet RequirementsAList normative requirements (RFC 2119 / BCP 14 "shall/should/may" statements) extracted from specifications, each cited back to its source clause.
Args:
spec_number: Filter by spec number, e.g. "23.501" or "RFC 9110" (optional)
obligation: Filter by strength - "must", "must_not", "should", "should_not", or "may" (optional)
search: Keyword to search within the requirement text (optional)
limit: Maximum number of requirements to return (default: 30, max: 100)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search | No | ||
| obligation | No | ||
| spec_number | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior, so the description adds value by explaining that each requirement is 'cited back to its source clause' and by documenting the default and maximum limit. This goes beyond the annotations without contradicting them.
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 well-structured: a single-sentence purpose followed by a clean Args list. Every line adds value, no fluff.
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 output schema exists and all parameters are fully documented, the description is quite complete. It covers the key behavior of citing source clauses and the filtering options, though it doesn't explicitly state the return type or error handling, which are likely covered by the output schema.
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 fully compensates by explaining each parameter in detail, including examples for spec_number, allowed values for obligation, and default/max for limit. This adds significant meaning beyond the bare 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 the specific verb 'List' and clearly identifies the resource as 'normative requirements extracted from specifications, each cited back to its source clause.' This distinguishes it from sibling tools like search_specifications or get_document_content, 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?
The description implies usage by focusing on listing normative requirements, but it does not explicitly compare with alternatives or state when not to use this tool. Given the distinct purpose, it's clear enough, but there's no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rfc_lineageRFC LineageAAn RFC's revision history. RFCs are immutable — an RFC is never revised, it is obsoleted or updated by a different RFC — so this Obsoletes/Updates graph, not a version diff, IS its change history. Use it to find out whether an RFC you depend on has been superseded.
Args:
rfc: The RFC, e.g. "7231", "rfc7231" or "RFC 7231"
| Name | Required | Description | Default |
|---|---|---|---|
| rfc | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context: RFCs are immutable, so the graph is the change history, and this is not a diff. This goes beyond the structured annotations and helps the agent understand the semantic 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?
The description is compact and well-structured, with a conceptual opening, a practical use case, and a clear Args block. The immutability explanation is slightly verbose but earns its place by clarifying why a graph is the history. No wasted sentences.
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 tool with one parameter and an output schema, the description covers the concept, usage, and input format thoroughly. It does not need to explain return values because an output schema exists. The only minor gap is not explicitly stating what kind of output (e.g., list of RFCs) but that is delegated to the schema.
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 compensate. It provides a clear meaning ('The RFC') and gives three accepted formats ('7231', 'rfc7231', 'RFC 7231'), which fully disambiguates the single parameter. This is sufficient for correct invocation.
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 provides an RFC's revision history via an Obsoletes/Updates graph, explicitly distinguishing it from a version diff. It also gives a concrete use case: 'find out whether an RFC you depend on has been superseded.' This differentiates it from sibling tools like diff_spec_versions and get_spec_dependents.
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 provides a clear 'when to use' statement with the superseded check, and explicitly excludes version diffs ('not a version diff'), giving context for selection among siblings. It does not name alternative tools, but the exclusion is sufficient for typical decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_schema_definitionsGet Schema DefinitionsALook up formal, machine-checkable structure defined in the specifications: ASN.1 types (3GPP RRC/NAS message grammars) and JSON Schema / OpenAPI models (5G Service Based Interfaces).
Prefer this over prose search when the question is about a message's *structure* — field
names, types, ranges, optionality. The definition is returned verbatim from the spec, so
it is exact rather than recalled.
Args:
name: Type or schema name, e.g. "RRCSetup", "MeasConfig", "SmContextCreateData"
spec_number: Restrict to a spec, e.g. "38.331"
kind: "asn1", "openapi" or "json_schema"
limit: Maximum definitions to return (default: 10, max: 25)
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| name | No | ||
| limit | No | ||
| spec_number | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds that definitions are returned verbatim from the spec and are exact rather than recalled, which is valuable behavioral context beyond annotations. It also mentions the limit constraint.
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 well-structured: a clear opening sentence, a usage recommendation, and a straightforward args list. Every sentence contributes meaning without unnecessary verbosity.
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 moderate complexity (4 optional parameters) and the presence of an output schema, the description sufficiently covers what the tool does, how to use it, and what to expect (verbatim spec definitions). The usage guidance and parameter details make it 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?
The input schema provides only titles and defaults with no descriptions (0% coverage). The description compensates fully by explaining each parameter with examples (e.g., 'RRCSetup', '38.331'), allowed values for 'kind', and default/max for 'limit'. This is essential and well done.
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 precise action ('Look up formal, machine-checkable structure') and names the exact resource types (ASN.1 types, JSON Schema/OpenAPI models). It also distinguishes itself from prose search by focusing on structural queries, making the tool's role clear.
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 recommends using this tool over prose search when the question is about structure (field names, types, ranges, optionality). It provides clear context for when to use it, though it doesn't list specific alternative siblings or state 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_series_overviewAInspectGet an overview of all specification series with document counts, reference statistics, and working group assignments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'Get' clearly indicates a safe, read-only operation. It also discloses what data is returned (document counts, reference statistics, working group assignments), which is useful behavioral context. It does not mention caveats like pagination or performance, but for a simple overview query 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 a single, concise sentence that front-loads the action ('Get') and lists the key output fields. Every word earns its place, with no redundant or vague phrasing.
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 read-only, parameterless aggregation tool with an output schema, the description is fully complete. It states the scope ('all specification series') and the exact data included. The output schema covers return details, and there are no prerequisites or side effects to disclose, so nothing is missing.
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 tool has zero parameters, so there is nothing for the description to explain. The input schema is empty, and schema coverage is 100% by default. Per the rubric, 0 parameters merits a baseline of 4, and the description adds no extraneous parameter details, leaving no 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 function: 'Get an overview of all specification series' and specifies the included data (document counts, reference statistics, working group assignments). This distinguishes it from sibling tools like get_database_stats or get_most_referenced_specs by focusing on series-level aggregated information.
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 a broad summary of series is needed, but it does not explicitly differentiate from alternatives or state when not to use it. Sibling tools like get_spec_metadata or get_database_stats overlap somewhat, yet no exclusions or comparisons are provided. The use case is implied rather than clearly prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_spec_dependentsAInspectGet all specifications that reference a given spec (reverse lookup).
Args:
spec_number: Specification number to find dependents of
max_results: Maximum results (default: 50)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| spec_number | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It conveys a read-only 'get' operation and explains the reverse-lookup behavior, but it does not disclose details like pagination behavior, ordering, or the effect of max_results beyond its default. For a read tool, this is adequate but minimal; it lacks richer context about what happens with large result sets or how output is structured (though an output schema exists).
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 with the core purpose, followed by an Args block that documents each parameter. The format is slightly awkward due to the indented code-block style, but every sentence adds value. It is not overly verbose, and the structure is clear.
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 simple lookup tool with two parameters, an output schema, and a clear scope (reverse lookup), the description provides enough information to invoke it correctly. It does not include usage examples or explicit tie-ins to sibling tools, but given the tool's simplicity and the presence of an output schema, it is largely complete. The absence of read-only annotation is compensated by the 'get' verb.
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 compensate. It explicitly explains spec_number as 'Specification number to find dependents of' and max_results as 'Maximum results (default: 50)', adding meaningful context beyond the bare schema titles 'Spec Number' and 'Max Results'. This is sufficient parameter-level guidance, though it could be more detailed about the semantics of max_results (e.g., pagination vs. limit).
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: 'Get all specifications that reference a given spec (reverse lookup).' It uses a specific verb ('get'), identifies the resource ('specifications that reference a given spec'), and adds the crucial scope 'reverse lookup' which distinguishes it from sibling tools like get_spec_references (which likely does forward lookup). This is a specific, non-tautological statement.
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 when to use the tool via the 'reverse lookup' phrase, signaling this is the tool for finding dependents rather than forward references. However, it does not explicitly name alternative tools or state when not to use it. The context is clear enough for an agent to decide, but it stops short of explicit exclusion or alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_spec_metadataBInspectGet enriched metadata for specifications with filtering.
Args:
spec_number: Filter by spec number (partial match)
series: Filter by series (e.g., "26" for 26.xxx codecs)
working_group: Filter by working group (e.g., "SA4")
doc_class: Filter by document class - "TS" or "TR"
limit: Maximum results (default: 50)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| series | No | ||
| doc_class | No | ||
| spec_number | No | ||
| working_group | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only says 'Get' implying read-only, but does not mention pagination, response size, authentication needs, or any caveats. The limit parameter hints at potential large result sets, but this is not explicitly discussed.
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 well-structured with a terse introductory sentence followed by a clear Args list. It avoids unnecessary prose, though the five-line parameter list is slightly longer than strictly minimal. Overall, it is efficient and scannable.
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?
An output schema exists, so return values do not need explanation. All five parameters are fully described, and the tool's purpose is clear enough. However, the vague term 'enriched metadata' and lack of sibling differentiation leave minor gaps, and no behavioral caveats are mentioned.
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 descriptions are absent (0% coverage), but the description fully compensates by explaining each parameter: spec_number is a partial match, series uses examples like '26', working_group uses 'SA4', doc_class restricts to 'TS' or 'TR', and limit has a default of 50. This adds meaningful semantics beyond the bare 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 states 'Get enriched metadata for specifications with filtering' which clearly identifies a verb, resource, and filtering scope. However, it does not differentiate from sibling tools like search_specifications or list_documents, leaving some ambiguity about what makes this tool distinct.
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 is provided for when to use this tool versus alternatives. The description lists filtering parameters but does not mention exclusions, prerequisites, or compare to sibling tools like search_specifications or get_series_overview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_spec_referencesBInspectGet all specifications referenced by a given spec.
Args:
spec_number: Specification number (e.g., "23.501", "26.230")
reference_type: Filter by type - "normative", "informative", "inline" (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| spec_number | Yes | ||
| reference_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention that the operation is read-only, what happens with invalid spec numbers, whether references are returned recursively, or any pagination/result limits. The description only covers the basic operation and filter options, leaving the agent without important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It delivers a clear one-sentence purpose, followed by a compact Args section that lists and explains the parameters. Every sentence is informative and there is no wasted wording, making it easy to parse quickly.
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 low-complexity tool with an output schema present, the description covers the core purpose and parameter details effectively. It does not explain return values, but the output schema handles that. The main gap is the lack of usage guidance, which is already penalized in dimension 2. Overall, the description is fairly complete for the tool's simplicity.
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 provides only type and title for both parameters, with zero description coverage. The description adds valuable semantics by giving example spec numbers ('23.501', '26.230') and enumerating possible reference_type values ('normative', 'informative', 'inline'). This compensates well for the schema's lack of detail, though it does not explain the meaning or behavior of these types.
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: 'Get all specifications referenced by a given spec.' It uses a specific verb and resource, and includes example spec numbers for clarity. However, it does not distinguish itself from sibling tools like get_spec_dependents or get_relationship_graph, so it lacks explicit sibling differentiation.
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 versus alternatives. The description simply states what the tool does without any context about suitable scenarios, exclusions, or preferred use cases. For instance, it does not mention that this tool is for outgoing references and get_spec_dependents for incoming references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_documentsList DocumentsAList available specification documents.
Args:
doc_type: Filter by document type - "3gpp", "ietf", or "mpeg" (optional)
search_pattern: Search pattern for spec number or title (optional)
limit: Maximum number of results (default: 20, max: 100)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| doc_type | No | ||
| search_pattern | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read-only, idempotent operation. The description adds a minor behavioral detail ('max: 100' for limit), but no additional context about pagination, sorting, or side effects.
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 succinct sentence plus a well-formatted Args list. Every line provides useful information without filler.
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 simple list tool with an output schema, the description covers the core operation and parameters. It is sufficient, though it does not mention return format or sorting, which are fairly expected for such a 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 description fully compensates for 0% schema coverage by explaining each parameter: doc_type with allowed values, search_pattern as a search over spec number/title, and limit with default and maximum. This gives agents clear parameter meaning.
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 'List available specification documents', identifying the specific verb and resource. However, it does not explicitly differentiate from sibling tools like search_specifications, so it is clear but not distinguished.
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 such as search_specifications. It only lists parameters, leaving the user to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_specificationsSearch SpecificationsASearch across 3GPP, IETF, and Multimedia specification documents using full-text search.
Args:
query: Search query terms (required)
doc_type: Filter by document type - "3gpp", "ietf", or "mpeg" (optional)
spec_number: Filter by specification number (optional)
max_results: Maximum number of results to return (default: 10, max: 50)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| doc_type | No | ||
| max_results | No | ||
| spec_number | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context such as full-text search capability and max_results limit (default 10, max 50). It does not detail output format, but an output schema exists to cover that.
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 well-structured. It starts with a clear purpose statement, then provides a clean Args list. Every sentence adds value; no redundant or vague text.
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, strong annotations, and existing output schema, the description is complete. It fully explains the search scope, all parameters, and key constraints. There is no significant missing information for an agent to select and invoke the tool 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 0%, so the description carries full responsibility for explaining parameters. It succeeds by documenting all four parameters: query (required), doc_type with allowed values, spec_number, and max_results with default and maximum. This goes beyond the schema by adding meaningful constraints and semantics.
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 across 3GPP, IETF, and Multimedia specification documents using full-text search. This specific verb+resource+scope effectively distinguishes it from sibling tools like semantic_search or list_documents.
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 clear context: use this tool when you need to perform a full-text search across these specific document repositories. It does not explicitly mention alternatives or exclusions, but the scope is well-defined. The detail on doc_type and spec_number filters helps the agent understand usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
semantic_searchSemantic SearchAPerform semantic search using vector embeddings with FAISS acceleration.
Args:
query: Natural language search query (required)
max_results: Maximum number of results to return (default: 5, max: 20)
similarity_threshold: Minimum similarity threshold 0.0-1.0 (default: 0.3)
index_type: FAISS index type - "hnsw", "ivf", or "flat" (optional, auto-selected)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| index_type | No | ||
| max_results | No | ||
| similarity_threshold | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already establish safety. The description adds meaningful behavioral context by mentioning FAISS acceleration, configurable index types (hnsw, ivf, flat), auto-selection, and default threshold. This goes beyond annotations to clarify technical 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?
The description is compact and front-loaded with the primary purpose. The Args section provides parameter details in a clean, scannable format. Every sentence serves a purpose, with no 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 the output schema exists, return values need no explanation. The description covers purpose, parameters, defaults, and technical details. It lacks explicit usage guidance or edge-case caveats, but for a straightforward search tool, it is nearly complete. Sibling distinctions are not addressed, slightly lowering 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?
Despite 0% schema description coverage, the description fully explains each parameter: query (natural language), max_results (default 5, max 20), similarity_threshold (range 0.0-1.0, default 0.3), and index_type (options and auto-selection). This compensates completely for missing schema descriptions.
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 'Perform semantic search using vector embeddings with FAISS acceleration.' This specifies both the verb and resource, and distinguishes it from siblings like search_specifications (which likely handles keyword search). The tool's purpose is 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 implies usage for semantic similarity searches but does not explicitly state when to use it versus alternatives like search_specifications. There is no 'when-not' guidance or mention of sibling tools. The context provided by the args (e.g., similarity threshold) suggests scenarios, but explicit alternatives are absent.
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!