The Lunenburg, Massachusetts town and school budget, every figure traced to its source document.
What a school budget line was in each year, AT ONE STAGE. The stage argument is required and singular on purpose: proposed, settled and actual are three different documents about the same year, and a growth rate measured from an actual to a budget is partly growth and partly the step between them. That mistake put a special education escalator 1.5 points too high here and was invisible until somebody asked how the number was derived. Note also that a budget line is NET — what the town must raise after grants, fees and state aid — so a line can rise because a grant ended rather than because anything cost more.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Part of the line name, e.g. "paraprofessional" | |
| stage | Yes | One stage. Never compare across stages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does so impressively: it reveals that lines are net of grants/fees/state aid, that stage values are separate documents, and that cross-stage comparisons produce misleading growth rates, including a concrete example of the harm. This goes well beyond a generic 'returns history' statement.
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 longer than average, but every sentence carries substantive content—purpose, stage caveat, and net definition—and the core purpose is front-loaded. The real-world example is slightly expansive, but it earns its place by illustrating a non-obvious failure mode; a 5 would require shedding that extra length.
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 two-parameter tool with full schema coverage, the description is nearly complete: it covers the data semantics, the key misuse trap, and the net definition. It doesn't describe the exact return shape, but there is no output schema and the tool is simple enough that this is a modest gap.
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 already documents both parameters with 100% coverage, so the baseline is 3. The description adds meaning beyond the schema by explaining why stage is singular and why mixing stages corrupts derived metrics, which is more than the enum alone conveys.
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 opening sentence states precisely what the tool returns—a school budget line's value in each year—and immediately attaches the critical constraint 'AT ONE STAGE.' This makes it easy for an agent to understand the tool's resource and scope and to distinguish it from generic siblings like query or list_datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs that stage is required and singular, warns against cross-stage comparisons, and explains why comparing actual to budget is a category error. It doesn't name sibling tools or give explicit when-to-use/not-to-use alternatives, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where a document came from: the publisher's URL, our copy, and its sha256 so a reader can check they have the same bytes. Use it to cite anything.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Part of a filename or path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the key returned information (publisher URL, our copy, sha256) and explains the purpose of the hash. However, it does not state whether the operation is read-only, what happens when no matching document is found, or any other edge-case 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 two sentences and every phrase earns its place. It front-loads the core concept, then gives the intended use case. There is no redundancy 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?
For a single-parameter tool with no output schema, the description covers the main essentials: what the tool returns and why a reader would use it. However, 'our copy' is somewhat vague, and the lack of an explicit return format or failure behavior leaves minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single required parameter, with 'name' described as 'Part of a filename or path.' The description adds no additional parameter-level guidance, so it does not improve on the schema. A baseline of 3 is appropriate because the schema already documents the parameter adequately.
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 identifies the tool's domain—document provenance—and names the concrete outputs (publisher URL, our copy, sha256). It does not use an explicit action verb like 'retrieve' or 'return', so the purpose is slightly implied rather than stated, and it does not contrast with any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage directive: 'Use it to cite anything.' This tells an agent when to invoke the tool. However, it does not mention when not to use it or name alternative sibling tools such as read_first or query, so the guidance is useful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every dataset in the archive, with THE YEARS EACH COVERS, its row count and its size. Call this before answering from prose: it is how you find out whether the archive holds data for the year and subject you are being asked about. 49 datasets covering the town and school budgets, the town ledger, staff rosters, out-of-district placements, elections, and fifteen years of annual town reports.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool returns a complete catalog of 49 datasets with years, row counts, and sizes, which is the key behavioral output for a parameterless listing tool. It does not explicitly state side-effect-free behavior, but the nature of the operation makes that low risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states what the tool returns, the second says when to call it, and the third summarizes coverage. It is front-loaded with the most important information and contains no 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 zero-argument listing tool with no output schema, the description is complete: it states what is listed, the metadata included, the number and subject coverage of datasets, and exactly when the agent should call it. Nothing needed for correct invocation 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 the baseline of 4 applies; there is no parameter detail for the description to add beyond the schema. The description's mention of returned attributes is about output semantics, not parameter 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 states a concrete action and resource: it lists every dataset in the archive with years, row count, and size. It clearly positions itself as an inventory/coverage lookup, which distinguishes it from retrieval or query siblings like document, query, and search_meetings.
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 gives explicit when-to-use guidance: call this before answering from prose to determine whether the archive has data for the requested year and subject. It does not name alternative tools or state when-not-to-use conditions, so it stops just 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.
Any question the other tools do not cover, as one read-only SQL statement over the archive database. SELECT or WITH only; a LIMIT is imposed if you omit one. Call read_first before computing anything and list_datasets to find table names. A query estimated to read more than 250,000 rows is refused — narrow it with a WHERE, or ask for one table at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | One SELECT statement. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses key behaviors: read-only constraint, automatic LIMIT insertion, and refusal of queries estimated to read over 250,000 rows. It does not describe result formatting or exact error behavior, but the main safety and execution traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: purpose, usage prerequisites, and safety/performance constraints are each covered. The most important scoping information is front-loaded before the parameter and table-name guidance.
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 open-ended SQL nature, the description is unusually complete: it sets scope, gives prerequisites, states allowed syntax, explains the limit and refusal behavior, and tells the agent how to narrow queries. The absence of an output schema is acceptable for arbitrary SELECT results, and nothing essential for a safe first call 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 schema already fully describes the single sql parameter, so the baseline is 3. The description adds meaningful constraints beyond the schema: SELECT or WITH only, LIMIT imposed if omitted, and row-estimate refusal, which helps the agent construct valid SQL.
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 identifies a catch-all read-only SQL query tool over the archive database, using a specific verb and resource. It distinguishes itself from siblings by explicitly claiming coverage of 'any question the other tools do not cover.'
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 explicit prerequisite steps: call read_first before computing anything and list_datasets to find table names. It also states when to use this tool and gives concrete query-shaping guidance such as SELECT/WITH only, narrowing with WHERE, and processing one table at a time.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The grain of every table and the specific ways to get a confident wrong answer out of this data. Read this before computing anything. It states, among others, that a budget and an actual must never be combined in one calculation; that a budget line is NET of grants and fees and is not what a thing costs; and that no budget line is mapped to a ledger account, so budget-to-actual at line level cannot be answered from this data at all.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It usefully discloses that the tool contains warnings and data caveats rather than raw query results, and provides concrete examples of what it states. It does not explicitly say whether it is a static read-only document or describe its return format, but 'read_first' and 'read this' make the read-only nature reasonably clear.
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 core purpose: it tells the agent to read before computing, then gives specific, high-value examples of the warnings inside. No sentence is wasted, and the most important directive appears early.
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 no-parameter informational tool, the description provides enough context for an agent to decide to call it first and to understand the kind of content it will receive. It does not specify the output format or size, but the absence of parameters and the explicitly informational nature make that gap minor.
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 has zero parameters, so there is nothing for the description to clarify beyond what the schema already shows. The baseline score of 4 applies because no parameter documentation 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 identifies the tool as a prerequisite reading resource that explains table grain and common analytical traps, and explicitly says to read it before computing anything. It is not a tautology and it is clearly distinct from query tools, though it does not explicitly name or compare against sibling tools like document or worked_examples.
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 gives an explicit usage trigger: 'Read this before computing anything.' This tells the agent when the tool should be called relative to other data operations. However, it does not explain when not to use it or mention alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which of the 1,422 published town meeting documents contain a word — every board, 2025 onward. Returns the board, the date and a citable URL for each. AN EMPTY RESULT MEANS THE WORD IS NOT IN THE INDEXED DOCUMENTS, which is not the same as nobody having said it: the archive starts in January 2025. It matches words exactly, so plurals are separate terms — search "jersey" and "jerseys" both.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | A single word, lowercase. Not a phrase. | |
| board | No | Optional board slug, e.g. school-committee |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it succeeds. It explains the critical false-negative behavior ('AN EMPTY RESULT MEANS...'), the January 2025 archive boundary, exact word matching, and pluralization. These are exactly the behavioral traits an agent needs to interpret results correctly.
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 purpose, then output, then critical caveats. Every sentence carries useful information and no sentence is wasted. The capitalized warning is loud but intentional and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately names the return fields (board, date, URL). It also covers scope, empty-result semantics, matching behavior, and the archive start date. The absence of pagination details is minor for a simple search 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?
Since schema_description_coverage is 100%, the baseline is 3. The description adds value by explaining exact-match behavior and pluralization, and reaffirms word-level semantics. Board parameter is already well explained in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact operation—searching published town meeting documents for a word—plus the scope ('every board, 2025 onward') and the output ('board, the date and a citable URL'). This is specific and distinctive relative to siblings like query and document.
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 makes the use case clear: an agent should call this tool when it needs to know which meeting documents contain a specific word. It does not explicitly name alternatives or exclusion cases, but the context is strong enough that an agent will not confuse it with other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many people the town PRINTED on a school staff roster, by year, school and kind of job. Uses our classification of the printed title, never the title itself, because the town has called the same job Tutor, Aide, Paraprofessional, Para, (para) and Sped Para across fifteen years. THIS IS A COUNT OF NAMES, NOT A STAFFING LEVEL: a roster carries no FTE, so a 0.4 music teacher and a full-timer are one row each, and it names no funding source, which is the question that usually matters. Grade appears only where the page happened to print it.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | Fiscal year as four digits, e.g. 2022 | |
| category | No | paraprofessional, teacher, administrator, counselor, nurse, psychologist, social_worker, speech_therapist, therapist, librarian, custodian, cafeteria, secretary, technology, specialist, coach |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and handles it well: it discloses that titles are standardized classifications rather than verbatim printed titles, explains why, clarifies the count semantics (0.4 and full-time both count as one row), and notes that grade only appears when printed. These are exactly the behavioral traps an agent needs to know.
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?
Four dense sentences with no filler; the core action is front-loaded and each later sentence adds a distinct, high-value caveat. The all-caps emphasis is used sparingly on the two most important semantic warnings.
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 2-parameter read-only tool with no output schema, the description is nearly complete: it defines the metric, classification behavior, and data limitations. It does not explicitly state the return format or what happens when both parameters are omitted, but the grouped-count language covers the main invocation need.
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 baseline is 3, but the description adds meaningful value by mapping kind of job to the category field and explaining that category values are classifications, not original titles. This prevents passing a raw historical title like Sped Para.
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?
Opens with a specific verb and resource: counts the people printed on a school staff roster, and specifies the grouping dimensions (year, school, kind of job). The emphasis that it is a count of names, not a staffing level, further prevents the most common misinterpretation.
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 gives clear context for when to use the tool and explicitly warns that it carries no FTE and no funding source, so an agent knows not to use it for staffing-level or funding questions. It stops short of naming an alternative sibling like budget_history for those needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
107 questions this archive can answer, each with the SQL that answers it. Every one is executed against the database on every build, so none of them is a claim. Start from the nearest one and edit it rather than writing a query from scratch.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that every example is executed against the database on every build, making them verified rather than speculative. This is a meaningful trust and quality signal, though the return format is not described.
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. The first sentence establishes content and validity, while the second gives the core usage directive. No filler or redundant information is present.
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 reference tool, the description adequately explains what is included, why it is reliable, and how to use it. It does not specify the exact output structure, but the nature of the content—questions with SQL—is sufficiently communicated.
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 accepts zero parameters and the input schema is empty, so there are no parameter semantics for the description to clarify. The baseline for a no-parameter tool is appropriately high.
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 identifies the tool as a collection of 107 pre-written, validated SQL examples for the archive. It conveys the resource's purpose and instructs the user to adapt existing examples. It does not explicitly name sibling tools, but the contrast with writing queries from scratch makes the purpose 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 instruction to start from the nearest example and edit it rather than writing a query from scratch provides clear, actionable guidance for when to use this tool. It lacks explicit when-not-to-use conditions or named alternatives, but the intended usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
budget_historydocumentlist_datasetsqueryread_firstsearch_meetingsstaffworked_examplesClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
The public record of local government: what your officials actually say and do, word for word.
Financial data, credit scores, and economic indicators for 14,800+ U.S. municipalities.
Cited, receipt-backed US home-buying data & calculators — education-only, every number sourced.
School enrollment, graduation rates, demographics, finance, and Title I data
Add one secure layer between your agents and this server.
Each tool targets a distinct concern: dataset discovery, data-grain warnings, safe budget lookups, staff counts, meeting full-text search, provenance, SQL catch-all, and query templates. The one soft boundary is that `query` could theoretically reproduce `budget_history` and `staff`, but the descriptions aggressively warn against naive SQL for those cases, which makes the specialization meaningful.
`list_datasets` and `search_meetings` follow a verb_noun pattern, but the rest mix bare nouns (`document`, `query`, `staff`), compound nouns (`budget_history`), an imperative phrase (`read_first`), and an adjective_noun (`worked_examples`). All names are readable and memorable, but no consistent syntactic convention holds across the set.
Eight tools is well within the ideal 3-15 range for a municipal archive server. Each tool earns its place: discovery, pre-query guidance, arbitrary SQL, two specialized wrappers that exist specifically to prevent costly analytical errors, full-text search over a separate corpus, provenance, and a curated set of executable examples.
The domain is well covered: dataset discovery, data pitfalls, arbitrary read-only querying, meeting document search, and citation. The catch-all `query` tool avoids most dead ends. Minor gaps remain — no full-text search over non-meeting documents like town reports and no bulk export/download dataset tool — but the 250k-row guardrail and publisher URLs partially mitigate these.
