TexasVoice
Server Details
The Texas Voice strives to be an honest and trustworthy source of information about Texas politics and government.
- 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.2/5 across 6 of 6 tools scored.
There is overlap between search and search_articles (both search but return different results), and between fetch and get_article (both retrieve full text but using different identifiers). While descriptions help distinguish them, an agent might still be confused about which to use in some cases.
Tool names use inconsistent patterns: single verbs (fetch, search), verb_noun (get_article, search_articles, list_recent_articles), and adjective_noun (popular_content). No clear convention is followed.
With 6 tools, the set is well-scoped for a publication content server. Each tool serves a distinct purpose without excessive overlap or missing essentials.
The tool surface covers core read operations: search, retrieve, list recent, and popular content. There are no obvious gaps for a read-only content API, though a tool to fetch articles by a direct URL or ID could be clearer.
Available Tools
6 toolsfetchFetch documentARead-onlyIdempotentInspect
Retrieve the full text of one document by the id returned from search.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Document id from search results |
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 the detail about using id from search, but does not provide significant additional behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and easy to parse.
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 read-only tool with one parameter and no output schema, the description is adequately complete. It explains the source of the id and the action. Could mention return format but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the id parameter. The tool description reinforces that the id comes from search, adding marginal value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full text of one document using an id from search, with specific verb and resource, and distinguishes from sibling tools like search and get_article.
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 mentions the id comes from search, providing context for when to use this tool. It does not explicitly state when not to use or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_articleGet articleARead-onlyIdempotentInspect
Fetch the full clean text of one article by its slug (the last path segment of an article URL).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Article slug, e.g. "my-article-title" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating safe, non-destructive, idempotent behavior. The description adds 'full clean text' which hints at return content but does not significantly expand beyond 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 a single sentence with no wasted words. It is front-loaded with the core action and resource, 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?
Given the tool has one required parameter, no output schema, and annotations covering safety, the description provides sufficient context for a retrieval tool. It doesn't address error cases (e.g., missing slug) but that is acceptable for this complexity level.
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%, and the description adds value by defining slug as 'the last path segment of an article URL', which clarifies the parameter beyond the schema's example. This extra context aids 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 explicitly states 'Fetch the full clean text of one article by its slug', clearly identifying the verb (fetch), resource (full clean text of one article), and mechanism (slug). This distinguishes it from sibling tools like list_recent_articles (lists multiple) and search_articles (search-based).
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 retrieving a single article by slug but does not explicitly guide when to use this tool versus alternatives like fetch or search_articles. No exclusions or when-not-to-use criteria are provided, which leaves some ambiguity for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_recent_articlesRecent articlesARead-onlyIdempotentInspect
List the most recently published articles from this publication.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 5, max 20) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds minimal value beyond stating the 'most recently published' context. No details on ordering, pagination, or data format are provided.
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, front-loaded sentence that efficiently conveys the tool's purpose without extraneous 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?
For a simple list tool with one parameter and no output schema, the description covers the core purpose. However, it lacks details like the ordering (e.g., by publish date) which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one well-described parameter (limit). The description does not mention parameters, but the schema already provides sufficient meaning, so no additional value is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'articles', with scope 'recently published from this publication'. It effectively differentiates from sibling tools like search or get_article 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 for fetching recent articles from the publication, but does not explicitly state when to avoid using it or compare it to alternatives like search_articles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
popular_contentPopular articlesARead-onlyIdempotentInspect
The most-read / most-requested articles, ranked by how often AI assistants have actually fetched them. Use for "what is your most popular article", "top reads", or to recommend what to read.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days (default 30, max 365) | |
| limit | No | How many to return (default 10, max 25) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds valuable context that ranking is based on real AI assistant fetch frequency, which is not in 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?
Two concise sentences: first defines the tool's output and ranking basis, second lists example queries. No fluff, each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two optional parameters, no output schema, and clear annotations, the description is complete. It explains the tool's purpose, usage context, and ranking methodology adequately.
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 'days' and 'limit' parameters. The description does not add additional meaning to these parameters, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns most-read/most-requested articles ranked by AI assistant fetches, and explicitly lists example queries like 'what is your most popular article' and 'top reads', distinguishing it from siblings (e.g., get_article for a single article, list_recent_articles for recency, search_articles for queries).
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 names use cases (most popular article, top reads, recommendations) but does not mention when not to use it or compare directly with sibling tools. However, the context signals and sibling names imply alternatives, making it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch contentARead-onlyIdempotentInspect
Search this site's content. Returns matching documents (id, title, url); pass an id to fetch for the full text.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that results contain id, title, and url, and that full text retrieval requires a separate tool call, which is valuable 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?
Two sentences efficiently convey purpose, output structure, and a follow-up hint. 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?
For a single-parameter search tool with full annotations, the description covers the purpose, return format, and guidance for subsequent actions, making 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?
Schema coverage is 100%, so the description does not need to explain parameters deeply. It does not add details about query syntax or format, maintaining the baseline score.
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 'Search this site's content,' clearly identifying a verb and resource. It distinguishes from siblings like `fetch` by indicating that search returns metadata only, while full text requires `fetch`.
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 states to use `search` for querying and then pass an ID to `fetch` for full text, providing a clear sequential usage hint. However, it does not explicitly mention when not to use this tool (e.g., for browsing all content) or name alternatives like `list_recent_articles`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_articlesSearch articlesARead-onlyIdempotentInspect
Search this publication's articles by keyword. Returns the best-matching titles, dates, canonical URLs, and short summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 5, max 20) | |
| query | Yes | Search keywords |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so the safety profile is clear. The description adds value by specifying the return fields (titles, dates, URLs, summaries), which is helpful 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 consists of two concise sentences with no superfluous words. It front-loads the purpose and efficiently states what is returned.
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 no output schema, the description adequately explains return values. With only two parameters (one required) and clear schema descriptions, the tool definition is complete for its 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 schema has 100% coverage, with descriptions for both 'query' and 'limit'. The tool description adds a general 'by keyword' context but no additional parameter-level detail beyond what the schema already 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 clearly states the specific action ('Search this publication's articles by keyword') and the result format ('returns the best-matching titles, dates, canonical URLs, and short summaries'). It effectively distinguishes from sibling tools like 'list_recent_articles' and 'get_article' by specifying keyword-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for keyword-based article searching, but does not explicitly state when not to use it or suggest alternatives. However, sibling tool names provide implicit usage context.
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!