Search + patterns, maturity assessment, context pricing, redaction checks - a practice as tools.
Score an agent workspace across six dimensions: canonical knowledge, memory and context economics, verification and oversight, safety and permissions, telemetry and cost, provenance and delegation. Two variants: "practitioner" takes 18 answers (a single operator's workspace), "org" takes 12 (an organisation's agent readiness). Each answer is an integer 0-3 in question order, where 0 is the least mature option offered and 3 the most. Returns per-dimension scores, an overall percentage, a maturity band, and the two weakest dimensions with the gap that matters there. The question text lives at https://jamesross.ai/tools/maturity-check (practitioner) and https://jamesross.ai/tools/agent-readiness (org). Read it before answering on someone's behalf.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | Answers in question order: 18 integers for "practitioner", 12 for "org". Each is 0-3. | |
| variant | Yes | "practitioner" for the 18-question workspace check, "org" for the 12-question organisational readiness check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses the scoring dimensions, the 0-3 answer semantics, and the full return payload (per-dimension scores, overall percentage, maturity band, weakest dimensions). It also flags the external source of the questions as a prerequisite. This is transparent and complete for a stateless scoring tool.
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 dense but well organized: purpose, variants, answer format, return shape, and prerequisite reading all appear in sequence with no filler. Every sentence contributes necessary invocation 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?
The tool has no output schema and no annotations, yet the description names every returned component and the input constraints, including the external question URLs. It also covers the nuance of answering on someone's behalf by directing to the source text. Nothing essential is omitted.
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 already covers both parameters fully (100% coverage), earning a baseline of 3. The description adds the exact expected array lengths for each variant, the meaning of 0-3 as least-to-most mature, and the requirement that answers be in question order, plus links to the source questions. That extra context justifies a 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 opens with a clear verb and resource: 'Score an agent workspace across six dimensions', listing the dimensions and the two variant modes. This makes the tool's purpose unambiguous, though it does not explicitly differentiate from sibling tools, whose names are clearly unrelated.
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 distinguishes the two variants ('practitioner' takes 18 answers, 'org' takes 12) and tells the agent to read the linked question text before answering. It provides clear context for how to invoke the tool, though it does not discuss alternative tools or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan text for the shapes of private content before it goes anywhere public: email addresses, absolute home paths, credential and token prefixes, private and link-local IPs, .local hostnames, and secret filenames. Returns a count per pattern class and a total, nothing else. The text you send and the substrings that matched are never stored, never logged and never echoed back. Only the counts are kept. A line carrying the marker "redaction-ok" is skipped. Accepts up to 100KB.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to scan. Up to 100KB; anything beyond that is truncated and the result says so. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure and pays it off: it states the exact return shape ('count per pattern class and a total, nothing else'), the no-retention/no-logging/no-echo guarantees, the 'redaction-ok' skip rule, and the 100KB input cap. This is comprehensive behavioral disclosure.
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?
Five short sentences each add a distinct fact: scope, return shape, privacy guarantee, marker behavior, and size limit. The text is front-loaded with the action and pattern list, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is complete: it specifies inputs, limits, return values, special marker handling, and privacy semantics. An agent has everything needed to decide whether to call it and what to expect.
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 of 3 applies and the schema already documents the text parameter including the truncation behavior. The tool description adds useful context about what is scanned, but it does not add parameter-level detail beyond what the input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Scan text for the shapes of private content') and names the exact pattern classes it detects, so an agent can identify what the tool does. It does not explicitly contrast itself with siblings such as lookup_pattern, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before it goes anywhere public' clearly situates the tool as a pre-publication safety check, giving a concrete when-to-use context. It does not list exclusions or name alternatives, but the intended usage is clear enough for the one-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the 18 architecture patterns behind this practice by keyword or by pattern number. Returns up to 3 matches, each with its number, title, the problem it opens on, and a link to the full text. Use it when you want the reasoning behind an agent-workspace design decision rather than a how-to.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keywords to match against pattern titles and summaries, e.g. "credentials", "silent failure", "context cost". A bare number 1-18 looks that pattern up directly. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the return shape (up to 3 matches with number, title, problem, link) and the search modes (keyword or number). It does not mention error handling or limitations, but the read-only nature is implied by a search/lookup function.
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 tightly written sentences. The first states the action and output; the second gives usage context. No redundancy, with the core functionality front-loaded. Every sentence contributes value.
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 lookup with no output schema and no annotations, the description is largely complete: it specifies the scope (18 patterns), the query method, and the response fields. Minor gaps remain (e.g., behavior on no matches, pagination) but are not critical for basic usage.
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 description already covers the 'query' parameter with examples and the special case of a bare number. The tool description reinforces this but adds no new semantic information beyond what the schema provides. Since coverage is 100%, a baseline score 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 it searches 18 architecture patterns by keyword or number and returns up to 3 matches with specific fields. It is distinct in purpose, though it does not explicitly name sibling tools or contrast with them, only implying a distinction from how-to guides.
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 guidance on when to use: 'when you want the reasoning behind an agent-workspace design decision rather than a how-to.' This gives a clear context, though it does not name alternatives like search_architecture or state when not to use the tool explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price a block of context by where it enters a session. The API is stateless, so the whole transcript is re-sent on every inference step, and a token costs its size times the number of turns left after it arrives. Returns the carried token volume, the cost of the block in USD, what the same read would have cost entering 20 turns from the end, and the multiplier between the two. Use it to decide whether a large read should move later in a session or into a subagent.
| Name | Required | Description | Default |
|---|---|---|---|
| read_mult | No | Cache-read price multiplier against input price. Default 0.1. | |
| entry_turn | Yes | Turn number at which the block enters the context (t). | |
| write_mult | No | Cache-write price multiplier against input price. Default 1.25. | |
| size_tokens | Yes | Size of the block in tokens (S). | |
| total_turns | Yes | Total turns in the session (T). Must be at least entry_turn. | |
| price_in_per_mtok | No | Input price in USD per million tokens. Default 5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It explicitly explains the stateless nature of the API, the token cost formula (size times number of turns left), and the return values. It stops short of explicitly stating it has no side effects, but the nature of a pricing calculation implies a non-destructive operation. The description is transparent about the model and outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: it states the purpose, explains the underlying model, lists the return values, and gives a concrete use case—all in four sentences. No wasted words. The critical information is front-loaded, and every sentence contributes to the agent's correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, 3 required, and no output schema, the description provides an unusually complete picture. It describes what the tool returns (carried token volume, cost in USD, comparative cost at 20 turns from the end, and the multiplier), explains the pricing formula, and gives an application scenario. Nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds value by explaining the cost model in relation to the parameters (e.g., 'a token costs its size times the number of turns left after it arrives'). This contextualizes size_tokens, entry_turn, and total_turns beyond their individual definitions. The description goes beyond simply restating schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Price a block of context by where it enters a session.' It clearly distinguishes this tool from siblings like assess_workspace or search_architecture, which are unrelated. The stateless context and pricing formula are explained succinctly, leaving no ambiguity about the tool's function.
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 states a use case: 'Use it to decide whether a large read should move later in a session or into a subagent.' It does not mention alternatives or when not to use it, but given the sibling tools are not competitors, the guidance is adequate. It provides clear context for when this tool adds value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell this server what capability you needed but didn't find here. Requests are logged and reviewed by a human; include no secrets or personal data.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional: what you were trying to do, and why the existing tools did not cover it. Up to 1KB. | |
| description | Yes | What you needed. Up to 2KB. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explicitly warns that requests are logged and reviewed by a human, and instructs users not to include secrets or personal data. This is meaningful context about side effects and privacy, though it doesn't describe the response/outcome after submission.
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 short sentences deliver the core instruction and the critical privacy warning without any filler. The main action is front-loaded and the security caveat is integrated naturally.
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 request-logging tool with fully documented parameters, the description covers what it does, when to use it, and the human-review/privacy implications. The only omission is what the agent should expect after submitting the request, but that is a minor gap given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no new parameter-specific details beyond the privacy guidance, which is appropriate but not compensating for a gap. Baseline 3 applies.
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 immediately states the core action: telling the server about a capability that was needed but not found. This clearly distinguishes it from the sibling tools, which perform analysis or lookup operations, whereas this is a feedback/request channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'didn't find here' provides a clear trigger condition for using the tool, and the context parameter reinforces that it is for gaps not covered by existing tools. It does not explicitly name alternatives or state when not to use it, but the condition is easy to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across the published architecture corpus: the 18 patterns and how they compose, the evaluation method, the seven learn-track modules, and the teardowns of other people's published agent systems. Returns ranked sections, each with its title, its source file, a snippet, and a link to the full text on GitHub. Use it when you want the passage itself rather than a pattern summary; lookup_pattern is the narrower tool that answers "which pattern covers this?". Every section is also readable in full as a resource under the architecture:// scheme (resources/list, resources/read).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many sections to return. 1-10, default 5. | |
| query | Yes | Search terms, e.g. "canonical copy", "silent failure", "cache write cost". Terms shorter than 3 characters are ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, and it discloses the behavior well: it is a read-only full-text search that returns ranked sections with title, source file, snippet, and GitHub link. It does not go into ranking details or no-result behavior, but it clearly sets expectations for a non-mutating retrieval tool.
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 sentences, each adding distinct value: scope, return format, when-to-use/alternative, and the resource-reading option. It is front-loaded with the tool's identity and wastes no 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?
Despite having no annotations and no output schema, the description fully equips an agent to call the tool correctly: it explains what is searched, what is returned, when to prefer it, and how the results relate to other access paths. Nothing essential is missing for a simple query-and-limit 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 100%, and both parameters (query and limit) are already documented with types, defaults, and example values. The description adds no parameter-level detail beyond what the schema provides, so the 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 names a specific verb and resource: "Full-text search across the published architecture corpus" — and enumerates exactly what the corpus contains. It distinguishes itself from the narrower sibling lookup_pattern, making its purpose unmistakable.
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 usage guidance is given: "Use it when you want the passage itself rather than a pattern summary," with a named alternative and the exact distinction between them. It also mentions that sections can be read via resources/list and resources/read, giving additional routing context.
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.
assess_workspacecheck_redactionlookup_patternprice_context_readrequest_capabilitysearch_architectureClaiming 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!
Governance maturity assessment, compliance gap analysis, and evidence-linked briefs for AI agents.
Document forensics: tamper/AI checks, fields, tables, identity, screening, tenders, citations.
Reviewed public-data search and execution with provenance and verifiable integrity receipts.
Read-only tools over the Safer Agentic AI framework: 238 patterns + 14 heuristics.
Add one secure layer between your agents and this server.
Most tools target clearly distinct functions: assessment, redaction checking, context pricing, capability requests, and search. The only potential confusion is between lookup_pattern and search_architecture, but their descriptions clearly differentiate scope — narrower pattern lookup versus full-text corpus search.
All tool names follow a consistent lowercase snake_case verb_noun pattern: assess_workspace, check_redaction, lookup_pattern, price_context_read, request_capability, search_architecture. There is no mixing of naming conventions or vague verbs.
Six tools is a well-scoped count for this server's purpose. Each tool represents a distinct capability within the agent workspace practice domain, and none feel redundant or superfluous.
The set covers the core workflows: maturity assessment, knowledge search, pattern lookup, context cost analysis, and feedback on missing capabilities. A minor gap is the lack of a dedicated tool to read or list full resources, though this is partially mitigated by the resources exposed under the architecture:// scheme.
