Cite or capture a web page; installs the capture extension in Firefox and Chrome.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 9 of 9 tools scored. Lowest: 3.3/5.
Most tools have clearly distinct purposes, with detailed descriptions separating singular versus batch citation extraction, and measurement data versus lists. However, extract_citation and extract_citations could be confused without reading the full descriptions, and how_to_capture vs install_extension have some functional overlap.
The majority of tool names follow a clear snake_case verb_noun pattern (e.g., extract_citation, list_measurements, install_extension). The outlier is how_to_capture, which is a phrase rather than verb_noun, but it remains readable and consistent in style with the rest.
Nine tools is well-scoped for a specialized lab covering citation extraction, measurement data, capture setup, and contribution entry. Each tool serves a distinct need without unnecessary bloat, and the count is appropriate for the apparent domain.
The tool surface covers the core workflows: single and batch citation extraction, retrieving measurement data and methods, capture guidance, extension installation, settings recommendations, and listing open work. There are no obvious dead ends; even unsupported citations include a next-step tool via how_to_capture.
extract_citationAInspectRead the citation details a web page declares about itself and return them as a structured record plus ready-to-import RIS and BibTeX. Covers journal articles, book chapters, conference papers, preprints, theses, reports, datasets, videos and plain web pages. Use when a source has to be cited, archived, or added to a reference manager. Says so plainly when a page turns out to be an error page or an access wall, instead of inventing a reference — and where it cannot finish, the reply carries a nextStep field naming what the user has to do in their own browser, with the capture extension that does it. Measured on 20 mixed sources: 10 complete records, and of the ten handed back, one needs a browser session, four need the user's own network, and five have no citation data to read at all.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Address of the page to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does exceptionally well. It discloses that it plainly reports error pages or access walls instead of inventing references, that a nextStep field is returned with browser actions, and even includes measured performance stats on 20 mixed sources. This goes far beyond typical descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core function, then usage, then behavior and performance. It is longer than average but every sentence contributes useful information. The measurement sentence is unusual but justifies reliability. 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?
Given there is no output schema, the description sufficiently explains what the tool returns (structured record, RIS, BibTeX) and handles failure modes (nextStep field). It also gives a concrete sense of expected success rates. For a single-parameter read tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter 'url' as 'Address of the page to read', giving 100% coverage. The description adds only that the page declares citation details about itself, but doesn't add syntax or format nuance. Baseline 3 is appropriate since the schema does the heavy lifting.
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 reads citation details a web page declares about itself and returns them as a structured record plus RIS and BibTeX. It also lists supported source types, which adds specificity. However, it does not explicitly distinguish itself from the sibling tool 'extract_citations', so it misses 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 description provides explicit usage context: 'Use when a source has to be cited, archived, or added to a reference manager.' It doesn't mention when not to use it or name alternatives, but the guidance is clear enough for typical selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_citationsAInspectUse when you have a reading list rather than one source — a bibliography to build, a set of links to verify before submitting, an archive to describe. Measured on 20 mixed sources: 10 became complete records in 8.1 s, 0.4 s each; the other 10 came back named rather than silently empty. Up to 50 addresses, five fetched in parallel. Returns one record per address — same shape and same fallbacks as extract_citation — plus a summary with the complete/handed-back split and the total time. Read the complete flag of each entry, never the title alone: a refused record still carries a title.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Addresses to read, at most 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses performance metrics, the 50-address limit, parallel fetching of 5, the return shape with a summary, and critically warns that refused records still carry titles, requiring the `complete` flag check. This is exemplary transparency.
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?
Every sentence earns its place: triggering usage, performance benchmarks, limits/parallelism, return shape, and a critical caveat about the `complete` flag. The progression is logical and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description covers the return format, summary contents, operational limits, and the essential flag-checking behavior. It also links to extract_citation for shape context. This is more than sufficient for correct 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?
Schema coverage is 100%, so the parameter is already documented as 'Addresses to read, at most 50'. The description repeats the limit and adds behavioral details (parallel fetching) but no new semantic meaning about the parameter itself, matching the baseline for high schema coverage.
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 is for multi-source reading lists, contrasting with the single-source sibling extract_citation, and explicitly notes it returns one record per address. The use cases (bibliography, links to verify, archive) reinforce a specific verb+resource scope.
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 opens with 'Use when you have a reading list rather than one source' and provides concrete scenarios. The reference to extract_citation as the singular equivalent implies the alternative, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_measurement_dataAInspectUse before quoting a figure: this returns what stands behind it — the values, the control run, and the conditions that limit them. Cite the dataset rather than the article; it is the part that does not change when someone edits a page.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | Yes | Dataset URL or bare filename |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the return includes values, control run, and limiting conditions, and emphasizes dataset stability ('does not change when someone edits a page'). It does not mention error behavior, but for a getter this is acceptable.
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, front-loaded with the primary use case ('Use before quoting a figure'), and every sentence adds value. 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 or annotations, the description explains the return content (values, control run, conditions) and the proper context for use. It lacks details on error handling but is still fairly complete for a getter 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% (the 'dataset' parameter is described as 'Dataset URL or bare filename'). The description adds no additional parameter syntax details, but reinforces that the dataset is the object to cite, which is helpful context. 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 the measurement data behind a figure (values, control run, conditions). It distinguishes this from sibling tools like extract_citation and get_method by focusing on raw data retrieval.
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 tells the agent to use this tool before quoting a figure and to cite the dataset rather than the article. It gives clear context but does not explicitly name alternative tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_methodBInspectFetch a reproducible method: reading a browser extension's permissions, measuring OCR recall with a control run, or choosing between print-to-PDF and screen capture. Omit the argument to list them.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral disclosure. It does reveal that omitting the argument lists available methods, but it doesn't state whether the operation is read-only, if it has side effects, or what happens for invalid names. This falls short of full transparency.
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 with a clear colon-separated enumeration of examples, followed by a direct instruction about the optional argument. Every clause adds value; there's no filler or 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 tool's simplicity (one optional param, no output schema), the description covers the core purpose, example methods, and argument behavior. However, it doesn't describe the return format or error behavior, which would be helpful for agents unfamiliar with 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?
The schema provides a single optional string parameter 'name' with no description. The description clarifies the argument's role: providing a name fetches a specific method, and omitting it lists all methods. It also gives concrete examples of method topics, giving the agent a sense of valid values, though it doesn't specify exact string formats.
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 fetches a reproducible method for specific tasks, citing examples like browser extension permissions, OCR recall, and print-to-PDF vs screen capture. The verb 'Fetch' and resource 'method' make the purpose unambiguous, though it doesn't explicitly distinguish from similar sibling tools like 'how_to_capture'.
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 through examples ('reading...', 'measuring...', 'choosing between...'), suggesting the tool provides procedural guidance for these scenarios. However, it lacks explicit 'when not to use' guidance or references to alternative sibling tools, so the context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
how_to_captureAInspectGet the runnable route for saving a web page that this endpoint cannot read — the sources it hands back. Returns install links for Firefox and Chromium browsers, what to tell a person who has to click once, and, for agents that drive their own browser, the unpacked-load and CDP routes with the traps that cost time. Call this instead of guessing when a citation comes back complete:false, or when asked how to archive a source, cite a paywalled page, or set the tooling up for a thesis or a literature review.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | How you act on the browser. 'input-events' if you produce real mouse or keyboard events (computer use, xdotool, an agent inside the user's browser); 'dom-only' for CDP or Playwright without OS input; 'no-browser' for plain HTTP; 'human' when writing instructions for a person. Omit if unsure — the answer then covers all of them. | |
| browser | No | Target browser, if known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It is transparent about what the tool returns (install links, instructions, CDP routes), qualifies that it handles pages 'this endpoint cannot read', and even warns about 'traps that cost time'. It lacks exact output shape, but for an informational tool this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then lists returns, then gives usage guidance. It is three sentences and dense, though phrases like 'the sources it hands back' and 'traps that cost time' are slightly vague and add a little wordiness.
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 two well-documented optional params, no output schema, and no annotations, the description covers the main return content and key use cases. It explains both the 'human' path and agent-driven browser paths, making it reasonably complete, though a bit more detail on output structure would be helpful.
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 provides 100% coverage with detailed enum descriptions for both parameters. The description adds value by linking agent behavior to route types and browser to install links, e.g., 'for agents that drive their own browser, the unpacked-load and CDP routes'. This goes beyond the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: getting a runnable route for saving a web page that the endpoint cannot read. It specifies the resource (web pages/citations), the action (get route/instructions), and the scope (install links, human instructions, CDP routes), distinguishing it from siblings like extract_citation.
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 explicit when-to-use guidance: 'Call this instead of guessing when a citation comes back complete:false, or when asked how to archive a source...' This is clear context, though it does not explicitly name alternative tools or when-not-to-use scenarios, so it stops 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.
install_extensionAInspectInstall or uninstall the capture extension in Firefox or Chrome without a window, without a click and without administrator rights — the runnable file shapes and commands, not a store link for someone to press. Call this when a capture route needs the extension present, when a run is finished and it should be gone again, or when asked whether an agent can set up a browser extension by itself. Firefox installs and removes in well under a second over its own control channel; Chrome fetches the signed store build itself. Also returns what the extension lets you do that this endpoint cannot, and the conditions under which installing on a machine is yours to decide.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | What you need. 'both' is the default and returns each direction — an install without its matching removal leaves a machine changed. | |
| browser | No | Target browser. Omit for both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses key behaviors: operates without a window, click, or admin rights; Firefox is fast over its own control channel; Chrome fetches the signed store build. It also mentions returning capability limits and permission conditions, going beyond baseline expectations.
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 informative but somewhat dense, with two long sentences. It front-loads the core action and usage triggers, and every sentence contributes value, though splitting into shorter sentences would improve readability.
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 is moderately complex (install/uninstall, two browsers, no admin rights), and the description covers the main scenarios, browser-specific mechanics, and return value hint. It lacks explicit error/edge cases and details on permission conditions, but schema enums and defaults fill much of the 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?
Both parameters have full schema descriptions (100% coverage), so the baseline is 3. The description does not add significant parameter-specific meaning beyond what the schema already provides, though it does reinforce the default 'both' action indirectly.
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 installs or uninstalls the capture extension in Firefox and Chrome, using specific verbs and resources. It also distinguishes itself from a mere store link, emphasizing it shapes files and commands. This is unambiguous and distinct from sibling tools.
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 lists when to call: when a capture route needs the extension, when a run finishes and removal is needed, or when asked about agent self-installation. It also notes what it does not do (capabilities the endpoint cannot do), providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_measurementsAInspectUse when a claim about browser tools, capture quality, OCR recall or citation extraction needs a number behind it — or when you want to check one of ours. Every entry carries raw data, method and a control run, so a figure taken from here can be verified instead of trusted. Start here.
| 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 disclosing behavior. It adds useful context that every entry includes raw data, method, and a control run, which implies verifiability. However, it does not explicitly state that the tool returns a list of all measurements, nor does it describe the return format, pagination, or whether it is read-only. The behavior is implied but not fully 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?
The description is two sentences, but the first sentence is long and lists multiple domains, making it somewhat dense. Still, each sentence earns its place: the first defines the use case, and the second explains the data content. It is reasonably concise but could be more front-loaded with the explicit 'list' action.
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 no parameters and no output schema, the description covers essential context: when to use it and what entries contain (raw data, method, control run). This is complete enough for a simple list tool, though it does not explicitly state the return type or whether it returns all entries. The lack of output schema raises the need for more explicit return details, but the 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?
The tool has zero parameters and the schema confirms this with 100% coverage. The description does not need to explain inputs, and the baseline for 0 params is 4. It adds no parameter-specific information, which is acceptable given the schema already fully documents the absence of parameters.
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 conveys the tool's role as a source of measurement numbers for browser tools, capture quality, OCR recall, and citation extraction. It implies the action of listing entries by saying 'Start here' and 'Every entry carries...', but it does not explicitly state the verb 'list' or contrast with sibling tools like get_measurement_data. The purpose is clear but not as direct as it could be.
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 when to use the tool: when a claim needs a number behind it or to check one of ours. It also instructs 'Start here', indicating it is the entry point. However, it does not mention when not to use it or point to alternatives such as get_measurement_data or get_method, which would strengthen the guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
open_workAInspectList what this project needs done, with enough context to start. Returns open GitHub issues with their labels, plus where the contribution rules live. Call this when asked to contribute to provinglab.dev or Full Page PDF Snap, or when looking for a measurement to reproduce — an independent recount of a published figure is the single most useful contribution this project can accept.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Filter by label. 'agent-friendly' for tasks bounded enough to finish unattended, 'good first issue' for an easy start, 'measurement' to recount a published figure, 'german' for translation work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the behavioral transparency burden. It uses active verbs 'List' and 'Returns' indicating a read-only operation, and adds contextual detail about the most useful contribution, but does not explicitly state a lack of side effects or permissions.
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 packs purpose, usage, and output into two sentences with no filler. Every clause earns its place, including the motivational note about measurement contributions, which clarifies priority.
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 optional parameter and no output schema, the description sufficiently covers what it does, when to use it, and what it returns. This fully equips an agent to invoke 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%, and the sole 'label' parameter is fully described in the schema. The tool description adds no extra parameter meaning, so the 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 'List what this project needs done' and specifies it returns open GitHub issues with labels and the location of contribution rules. It distinguishes itself from sibling tools by framing it as the contribution entry point, especially for measurement reproduction.
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 instructs 'Call this when asked to contribute to provinglab.dev or Full Page PDF Snap, or when looking for a measurement to reproduce'. This provides clear, context-rich guidance on when to invoke the tool, with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_settingsAInspectThe capture settings that fit a given purpose, each with the measurement behind it or an explicit note that none exists. Pass purpose as citation, figure, archive or ocr. Use before capturing: the file that comes out is between 8.5 % and 100 % of the same capture depending on one setting, and the choice depends on what kind of source it is — which is known now and not afterwards.
| Name | Required | Description | Default |
|---|---|---|---|
| purpose | No | what the capture is for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool outputs settings with measurement rationale or an explicit 'none exists' note, and it warns about output file size variation (8.5% to 100%) depending on a setting. This is meaningful behavioral disclosure, though it doesn't explicitly state the tool is read-only.
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: function, usage, and rationale. Every sentence earns its place, no fluff. The key information 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?
The description explains what the tool returns, how to use it, and why timing matters. For a simple one-parameter tool with no output schema, this is complete enough for an agent to correctly invoke it and interpret results.
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 covers the parameter and enum values 100%, but the description adds context: purpose values are listed and the choice matters because source kind is known before capturing. This goes beyond the schema's 'what the capture is for' and justifies the parameter.
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 recommends capture settings for a given purpose, with specifics about what is returned (measurement or explicit note). It distinguishes from siblings like extract_citation and get_measurement_data by focusing on pre-capture settings recommendation.
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 says 'Use before capturing' and explains why the timing matters (source kind known now, not afterwards). While it doesn't name alternative tools, the context and purpose are clear enough for an agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!