Proximens Oracle
Server Details
1000+ Generative Engine Optimization (GEO) principles exposed via MCP for AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.5/5 across 8 of 8 tools scored.
Each tool has a clearly distinct purpose: single URL audit, bulk search, URL comparison, principle retrieval, stats, category listing, semantic search, and brief synthesis. No two tools overlap in function.
All tools follow the consistent pattern 'proximens_oracle_verb_noun' using snake_case. Verbs are descriptive and actions are clear, with only minor variation like 'bulk_search' vs 'search_principles' which is still understandable.
With 8 tools, the server is well-scoped for a specialized GEO knowledge base and auditing service. Each tool is necessary and there are no redundant or missing core operations.
The tool set covers the full workflow: discover (search, list categories), retrieve (get principle, get stats), analyze (audit, compare), and generate (synthesize brief). No obvious gaps for the intended domain.
Available Tools
8 toolsproximens_oracle_audit_urlAudit URL against Proximens GEO OracleARead-onlyInspect
Pro-tier. Fetch and analyze a web page, then audit it against the Proximens Oracle GEO principles across all major GEO dimensions (structured data, crawler access, content depth, freshness, E-E-A-T, multimodal). INPUT: url (required, http/https); optional mode ("fast" = quick signal checks, returns in seconds — the default; "deep" = a full AI-synthesized consultancy report in Dutch with a 7-dimension scorecard and sector benchmark, takes ~30-50s), client_name (report header), branche_hint ("main:sub", e.g. "health_wellness:yoga_studio"), max_issues (1-25, default 10). RETURNS: JSON with a 0-100 score, severity-ranked issues (critical/major/minor) each with a finding and an actionable suggestion, top recommendations, and a markdown report; deep mode additionally returns score_set (7 GEO dimensions), sector (benchmark cohort), and a full consultancy-grade report_markdown (deep_mode="timeout_fallback" means the synthesis exceeded its budget and the fast result was returned instead). USE fast mode for quick checks and bulk triage; USE deep mode when you need a client-ready audit report. Free tier is blocked.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL to audit | |
| mode | No | fast = quick signal checks (seconds); deep = full AI-synthesized consultancy report with sector benchmark (~30-50s) | fast |
| max_issues | No | Maximum issues to return (default 10) | |
| client_name | No | Optional client identifier for the audit report header | |
| branche_hint | No | Branche hint in "main:sub" format, e.g. "health_wellness:yoga_studio". If omitted, principles are matched without branche filter. |
Output Schema
| Name | Required | Description |
|---|---|---|
| _wm | No | |
| url | Yes | |
| _meta | No | |
| error | No | |
| score | No | |
| sector | No | Detected sector benchmark cohort (deep mode only) |
| status | Yes | |
| signals | No | |
| audit_id | Yes | |
| deep_mode | No | Deep-mode outcome: ok = full synthesized report; timeout_fallback = synthesis exceeded budget, fast result returned |
| score_set | No | 7-dimension GEO scorecard (deep mode only) |
| recommendations | No | |
| report_markdown | No | |
| matched_principles | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds transparency about mode behavior, timeout fallback ('deep_mode="timeout_fallback"'), and return structure, which is valuable beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with purpose, then parameters in a clear INPUT block, and return values. It is somewhat lengthy but front-loads key information. Every sentence adds value, though could be slightly more concise.
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 (5 parameters, output schema exists), the description covers all necessary aspects: input requirements, modes, optional parameters, return format (including deep mode specifics and fallback), and usage hints. It is fully self-contained.
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 baseline is 3. The description adds meaning by explaining mode options in detail, specifying 'branche_hint' format (main:sub), and clarifying that 'max_issues' has a default of 10. This improves usability beyond the schema alone.
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 audits a URL against Proximens Oracle GEO principles, specifying the verb ('audit'), resource ('URL'), and scope ('across all major GEO dimensions'). It effectively distinguishes from sibling tools like 'proximens_oracle_compare_urls' and 'proximens_oracle_bulk_search' by focusing on a single URL audit.
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 offers explicit guidance on when to use 'fast' mode for quick checks and 'deep' mode for client-ready reports, and mentions the free tier is blocked. However, it does not explicitly exclude use cases or compare against sibling tools, leaving some ambiguity about when to choose this over alternatives like 'proximens_oracle_compare_urls'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proximens_oracle_bulk_searchBulk Search Proximens OracleARead-onlyIdempotentInspect
Pro-tier. Run many GEO-principle searches in a single fast call. INPUT: queries (array of 2-100 natural-language strings, each 3-500 chars); optional top_k_per_query (1-10, default 5) and category filter. RETURNS: JSON with a results array (per query: the query, its matched principles, and a count), plus total_queries, total_matches and processing time. USE WHEN you need many lookups at once, e.g. a full-site audit or a keyword list, instead of repeated search_principles calls.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | ||
| category | No | ||
| top_k_per_query | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| _meta | No | |
| results | Yes | |
| total_matches | Yes | |
| total_queries | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context: it returns processing time, results array, and specifies input constraints (array size, length). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear 'INPUT', 'RETURNS', and 'USE WHEN' sections. Every sentence adds value, no redundancy, and it's appropriately concise for a bulk operation tool.
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 and comprehensive annotations, the description fully covers usage context, return format, parameter details, and when to use. It leaves no gaps for an agent to misinterpret.
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 0% schema description coverage, the description fully explains all parameters: queries (array of 2-100 natural-language strings, 3-500 chars), optional top_k_per_query (1-10, default 5), and category filter. It adds meaning beyond schema enums and defaults.
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 'Run many GEO-principle searches in a single fast call', specifying the action (bulk search) and resource (GEO principles). It distinguishes from the sibling tool 'search_principles' by emphasizing batch capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'USE WHEN you need many lookups at once, e.g. a full-site audit or a keyword list, instead of repeated search_principles calls.' This clearly states when to use and offers an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proximens_oracle_compare_urlsCompare URLs against Proximens GEO OracleARead-onlyInspect
Pro-tier. Fetch two web pages (your URL and a competitor's) and audit both against the Proximens Oracle GEO principles using the same audit engine as audit_url, then compute the delta. INPUT: self_url and competitor_url (both required, http/https). RETURNS: JSON with a 0-100 score per URL (same scoring as audit_url), the principles each page satisfies, the principles each page VIOLATES that the other satisfies (delta_principles), and strategic insights on where to close the gap. USE WHEN you want a competitive GEO gap analysis between your page and a rival's.
| Name | Required | Description | Default |
|---|---|---|---|
| self_url | Yes | Your URL to audit | |
| competitor_url | Yes | Competitor URL to compare against |
Output Schema
| Name | Required | Description |
|---|---|---|
| _meta | No | |
| error | No | |
| insights | Yes | |
| self_url | Yes | |
| self_score | Yes | |
| self_matched | Yes | |
| competitor_url | Yes | |
| competitor_score | Yes | |
| delta_principles | Yes | |
| competitor_matched | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive, read-only behavior. The description adds that it fetches two web pages and returns scores, principles, delta principles, and insights, but does not go beyond what annotations imply. Additional behavioral context (e.g., network calls) is implied but not explicitly harmful.
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 one concise paragraph with clear sections (purpose, input, output, use case). It is front-loaded and 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?
Given the presence of an output schema and annotations, the description is complete: it explains the tool's purpose, required inputs, output structure (including specific keys like delta_principles), and use case. The agent has enough information to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds minimal extra meaning (confirms http/https format, reuse from schema). Baseline of 3 is appropriate as the schema already provides adequate parameter documentation.
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 compares two URLs using the Proximens Oracle GEO engine and computes a delta. It uses specific verbs ('Fetch', 'audit', 'compute') and distinguishes from sibling 'audit_url' which handles single URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'USE WHEN you want a competitive GEO gap analysis between your page and a rival's', providing a clear context. It does not explicitly list when not to use, but the condition is sufficiently specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proximens_oracle_get_principleGet GEO principle by IDARead-onlyIdempotentInspect
Fetch one GEO principle from the Proximens Oracle by its UUID. INPUT: id (UUID, normally taken from a prior search_principles result). RETURNS: a single principle as JSON with id, title, summary, category and confidence; Pro/Enterprise tiers additionally return full_text, source_url, source_type, evidence_count and the last-validated timestamp. USE WHEN you already have a principle id and need its full detail — typically to drill down after search_principles.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Principle UUID (from search_principles results) |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| _wm | No | |
| title | Yes | |
| summary | Yes | |
| branches | No | |
| category | Yes | |
| full_text | No | |
| confidence | Yes | |
| similarity | No | |
| source_url | No | |
| source_type | No | |
| upgrade_hint | No | |
| evidence_count | No | |
| source_diversity | No | |
| last_validated_at | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, destructiveHint, idempotentHint. Description adds tier-dependent return fields (Pro/Enterprise) and source of ID. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with explicit INPUT/RETURNS sections. Front-loaded with 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 single parameter and read-only nature, description fully covers input origin, tier-specific outputs, and usage context. Output schema exists, so return details are sufficient.
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 has 100% coverage for the single UUID parameter. Description adds context that ID comes from 'prior search_principles result', meaningfully supplementing 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 specifies 'Fetch one GEO principle by UUID' with clear verb+resource. It distinguishes from sibling 'search_principles' by noting it is for drill-down after obtaining an ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'USE WHEN you already have a principle id...' and gives typical usage pattern. No explicit when-not, but context is sufficient given simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proximens_oracle_get_statsGet Oracle statisticsARead-onlyIdempotentInspect
Return live aggregate statistics for the Proximens GEO Oracle knowledge base. INPUT: none. RETURNS: JSON with total_principles (high-confidence count), total_categories, and on Pro/Enterprise also extended quality metrics (full corpus size and a confidence_distribution) plus the last-validated timestamp. USE WHEN you need to gauge the size and quality of the corpus before relying on it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| tier_hint | No | |
| fetched_at | No | |
| total_evaluated | No | |
| total_categories | Yes | |
| total_principles | Yes | |
| last_validated_at | No | |
| last_distillation_at | No | |
| confidence_distribution | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating a safe read operation. The description adds value by disclosing that the statistics are 'live,' includes tier-specific behavior (Pro/Enterprise extended metrics), and specifies the JSON return structure, which goes 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?
The description is extremely concise, consisting of two sentences and a 'USE WHEN' clause. It is front-loaded with the main action and returns, with no extraneous words. 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?
For a parameterless tool with an output schema (present but not shown), the description adequately explains the return values and usage context. It covers the main purpose and when to use. It could potentially mention prerequisites or rate limits, but given the simple nature, it is mostly 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 100% with no parameters. The description redundantly states 'INPUT: none,' which adds no new meaning beyond the schema. Baseline 3 is appropriate as the description does not compensate for any missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live aggregate statistics for the Proximens GEO Oracle knowledge base. It specifies the return fields (total_principles, total_categories, etc.) and distinguishes from sibling tools like get_principle or search_principles by focusing on aggregate data rather than individual records.
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 says 'USE WHEN you need to gauge the size and quality of the corpus before relying on it,' providing clear context. It does not explicitly state when not to use or compare to alternatives, but the usage guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proximens_oracle_list_categoriesList GEO principle categoriesARead-onlyIdempotentInspect
List the GEO principle taxonomy of the Proximens Oracle with a live count of high-confidence principles per category. INPUT: none. RETURNS: JSON with a categories array of {category, count, description} sorted by count, plus a reconciled total that matches get_stats.total_principles. Categories: technical, structured-data, ai-search, content, e-e-a-t, freshness, multimodal, user-signals, performance, query-intent, internal-linking, mobile, other. USE WHEN you want to discover which categories exist before narrowing a search_principles call with the category filter.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| cached | Yes | |
| categories | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, idempotentHint=true, destructiveHint=false; the description adds details about the live count, JSON structure with specific fields, and a reconciled total matching get_stats, which enriches behavioral understanding 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?
The description is a single paragraph with all essential components: purpose, input, return format, usage guidance, and a list of categories. Every sentence adds value, and it is front-loaded.
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 zero parameters and a simple output, the description fully covers the tool's behavior, output structure, and relationship to other tools. The output schema exists, so no need to detail return values further.
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?
No parameters exist, so schema coverage is 100%. The description explicitly notes 'INPUT: none,' which is clear. Per guidelines, with 0 parameters, baseline is 4.
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 lists GEO principle categories with a live count, and distinguishes itself from siblings by referencing search_principles and get_stats.
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 explicit guidance: 'USE WHEN you want to discover which categories exist before narrowing a search_principles call with the category filter.' This is clear and helpful, though it lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proximens_oracle_search_principlesSearch GEO principles (Proximens Oracle)ARead-onlyIdempotentInspect
Semantic search over the Proximens GEO Oracle: a curated, continuously-updated knowledge base of 3.000+ verified Generative Engine Optimization (GEO/AEO) principles, each graded by a 0-1 confidence score and traceable to a verified source. INPUT: query (natural language, 3-500 chars); optional category (one of 13 GEO categories), top_k (1-25, default 10), min_confidence (0-1, default 0.5). RETURNS: ranked principles as JSON, each with id, title, summary, category, confidence and a relevance score; Pro/Enterprise tiers additionally return full_text and source. USE WHEN you need evidence-backed answers about how AI search engines (ChatGPT, Perplexity, Gemini, Google AI Overviews, Copilot) select, rank and cite web content.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query (e.g. "schema markup for local businesses" or "how to optimize for ChatGPT citations") | |
| top_k | No | Number of principles to return (max 25) | |
| category | No | Filter by category (one of 13 GEO categories) | |
| min_confidence | No | Minimum confidence score (0-1). Default 0.5 filters noise; raise to 0.8+ for high-confidence claims only |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| tier_note | No | Free-tier hint when top_k was capped |
| query_used | Yes | |
| total_in_database | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns ranked principles with relevance scores, tier-dependent fields, and explains input constraints thoroughly.
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 paragraph is well-structured: purpose, input, output, usage. Could be slightly more concise, but no redundant 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?
Covers all aspects: knowledge base size, input parameters, return fields, tier differences, and usage scenario. Output schema exists but description provides sufficient 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%, but description adds value: explains query length range, default top_k, min_confidence purpose ('filters noise; raise to 0.8+ for high-confidence'), and category listing.
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 performs semantic search over a curated knowledge base of GEO principles, and distinguishes from sibling tools like bulk_search and get_principle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'USE WHEN you need evidence-backed answers about how AI search engines select, rank and cite web content.' Provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proximens_oracle_synthesize_briefSynthesize Content Brief from Proximens OracleARead-onlyInspect
Generate a structured, GEO-optimized content brief for a topic using the Proximens Oracle. INPUT: topic (3-200 chars); optional target_branche (one of 7 verticals), word_count_target (300-5000, default 1500) and up to 3 competitor_urls. RETURNS: JSON with a suggested H1 and H2 section structure with key points, the principles the content should address, and (Pro/Enterprise) FAQ suggestions and recommended schema.org markup. USE WHEN you need to brief a writer so a page is built to be cited by AI search engines.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| target_branche | No | ||
| competitor_urls | No | ||
| word_count_target | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| _meta | No | |
| topic | Yes | |
| brief_id | Yes | |
| schema_markup | No | |
| faq_suggestions | No | |
| suggested_structure | Yes | |
| estimated_word_count | Yes | |
| principles_to_address | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds value by detailing return structure (JSON with H1/H2, principles, FAQ, schema markup) and input constraints, surpassing what annotations provide.
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 paragraphs are concise and front-loaded: first paragraph states purpose and input details, second covers returns and usage. Every sentence is informative with 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?
Given presence of output schema, the description need not explain return values in detail but does so helpfully. It covers inputs and outputs adequately, though 'principles' could be elaborated. Overall complete for a complex 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?
Schema description coverage is 0%, but the description fully lists all parameters with constraints (e.g., topic 3-200 chars, target_branche enum, etc.), adding meaning beyond the schema. This compensates well.
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 it generates a structured GEO-optimized content brief for a topic, using specific verb 'Generate' and resource 'content brief'. It distinguishes from sibling tools like audit_url or compare_urls by focusing on briefing content.
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 includes explicit 'USE WHEN' guidance: when briefing a writer for AI search engine citation. It does not mention alternatives or exclusions, but the context from sibling tools makes it clear this is for brief creation.
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.
Discussions
No comments yet. Be the first to start the discussion!