TPT MCP

by grahamwaters

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct stage of the listing workflow—local prep, browser inspection, submission, verification, and browser lifecycle. Mild ambiguity exists among tpt_get_product, tpt_prepare_product, and tpt_verify_saved_product, all of which involve validation of product metadata/files, and between tpt_inspect and tpt_category_options which both read the current form.
Naming Consistency4/5
The tpt_ prefix and snake_case naming are consistent, and most tools follow a verb_noun pattern such as list_products, prepare_product, or choose_category. The pattern is slightly broken by noun-only names like category_options and product_status, and the verb-only tpt_inspect.
Tool Count5/5
Twelve tools is well-scoped for a browser-automation listing workflow, with each tool mapping to a meaningful step from login to upload to submission to verification. The count is within the ideal range and no tool feels redundant.
Completeness4/5
The tool set covers the core lifecycle of creating, submitting, checking, verifying, and formatting a product listing, including login, category selection, upload, and status tracking. Obvious gaps are the lack of explicit update/delete tools for existing listings and no direct way to edit uploaded assets, but these can be partially addressed through verify and format tools.
Average 3.4/5 across 12 of 12 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the read-only nature is disclosed, but the description's 'Validate files' behavior is left unexplained. It also does not mention what happens on validation failure or what the read operation returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but the front-loaded 'Validate files' clause is tangential and not clearly related to the tool's primary function of reading product metadata. It is concise but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only a vague resource description, the tool lacks essential context about return values, error behavior, and how 'prepared product metadata' differs from other product-related tools. The description is too thin to fully support correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' has no description in the schema, and the tool description does not explain what kind of identifier it is. The pattern ^[a-z0-9-]+$ implies a formatted ID, but the meaning of that ID is entirely unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb and resource—'read prepared product metadata'—but the phrase 'Validate files' is confusing and not clearly tied to the tool name or its siblings. It does not sufficiently distinguish this tool from tpt_product_status or tpt_list_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool, what prerequisites exist, or when to prefer it over sibling tools. The word 'prepared' hints at a workflow, but no explicit usage direction is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Read,' implying a read-only operation, but the annotations set readOnlyHint=false and destructiveHint=true. This is a direct contradiction. The description also does not disclose any potential side effects or browser-state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the verb, and contains no filler. However, its brevity comes at the cost of important behavioral context, so it is efficient but not fully 'appropriate' in content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and contradictory annotations, the description fails to explain return behavior, side effects, or the tool's role among many siblings. For a tool annotated as destructive, this is a significant and dangerous gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'field' has no description in the prose and schema description coverage is 0%. The enum values are provided in the schema, but the description does not explain how the tool's 'category options' relate to fields like Tax Code, Subject Area, or Format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Read current category options from the TPT form.' The word 'current' and the category-options focus help distinguish it from sibling tools like tpt_choose_category, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this tool versus siblings, no prerequisites, and no indication of whether it should be used before tpt_choose_category or during form preparation. The usage context is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this may mutate state. The description adds context about verifying saved files and listing fields before confirming a draft or active listing. However, it does not clarify what side effects occur when reopening or verifying a saved product, and the relationship between 'verifying' and 'recording' is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action ('Reopen a saved seller product'). Both sentences convey useful workflow context without excessive detail, though the second sentence's role could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and annotations that only hint at safety, the description leaves out important operational details: what the agent should do with the reopened product, what 'verified' looks like, whether the tool itself records the draft/active listing, and what the result or next step is. The description is not sufficient as a standalone guide for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden for explaining parameters. It hints that 'remoteId' is the observed TPT numeric ID, but it never explains what 'id' is, how the two IDs relate, or where either value comes from. The pattern constraints in the schema help but do not convey semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Reopen a saved seller product' and 'Verify saved files and listing fields'. It conveys a verification/reopen workflow, though it does not sharply distinguish itself from sibling tools like tpt_get_product, and the phrase 'before recording' leaves the tool's exact scope slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. It implies the tool is for reopening and verifying saved products before recording, but it never names alternatives or explains what distinguishes this from tpt_get_product, tpt_product_status, or tpt_inspect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is not read-only and is destructive, and the description adds the useful behavioral note that submission/saving is a separate step. It still leaves ambiguity about whether the tool replaces existing content, modifies in place, or only stages formatting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the main action, and contains no filler. The one caveat around 'Submit separately to save' is efficiently placed at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two required parameters with zero schema coverage and no output schema, this description is insufficient for reliable invocation. It conveys a rough workflow purpose but does not explain what id and remoteId mean, what 'existing matching product' refers to, or what the expected result/return value is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the required id and remoteId parameters. It does not even hint that these identifiers correspond to the 'existing matching product,' leaving the agent without enough information to populate the fields correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action and resource: entering formatted paragraphs, bold headings, and bullet lists into an existing matching product. It is clear that this tool is about formatting a saved product's description, but it does not distinguish itself from nearby siblings such as tpt_prepare_product or tpt_submit_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Submit separately to save' gives useful workflow context, implying this tool is a formatting step and not the final save action. However, it does not explicitly state when to choose this tool over alternatives, nor does it mention exclusions or prerequisites such as whether the product must already exist and be verified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=false and destructiveHint=true, so the description does not need to restate that this is mutating. It does add useful behavioral context by requiring an 'exact option observed' in the current form, which aligns with openWorldHint=true. It does not describe side effects like form navigation or state changes, but annotations cover the basic safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the core selection constraint efficiently. It could add more guidance without bloating, but as written it is well-structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the enum and annotation cover a lot: allowed fields, destructive intent, open-world choices. Still, there is no mention of how to obtain the 'observed' options, how this relates to tpt_category_options, or what happens after selection. Given destructiveHint=true, a little more context about the mutation would make the tool safer to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description had to carry the load for explaining 'field' and 'value'. It only implies that 'value' is an observed option; it never explains that 'field' selects which form control to update, nor that the value must correspond to the allowed options for that field. The enum on 'field' helps but still does not define semantics for 'value'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Choose') and a specific resource ('option observed in the current TPT form'), so an agent can tell this is a selection action rather than a listing or inspection action. Its main weakness is that the tool name limits it to 'category' while the schema actually supports six different field types, so the description does not fully resolve that mismatch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Observed in the current TPT form' clearly implies the value must come from something previously inspected or listed, and it warns against arbitrary values. However, there is no explicit statement about when to use this tool versus siblings like tpt_category_options or tpt_inspect, and no alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with those by saying 'Read local submission journal.' It adds useful behavioral context by clarifying that the source is local, not remote, and that the status 'unverified' should not be equated with publication. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the second sentence adds a meaningful interpretation caveat. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and read-only annotations, so the description covers the basic operation and a key status interpretation. However, the missing id semantics and lack of any return-value guidance leave noticeable gaps for an agent needing to act on the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the required 'id' parameter at all. It is unclear whether 'id' refers to a product ID, a submission journal entry ID, or something else. With only one parameter, the description needed to clarify its meaning but failed to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Read local submission journal.' This clearly indicates a read operation on a local store, and the term 'local' distinguishes it from sibling tools like tpt_get_product and tpt_inspect that likely operate on remote/browser state. The added warning 'Unverified does not mean published' reinforces the tool's purpose of interpreting submission status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to check local submission state, especially after submission flows, but it never explicitly states when to use this tool versus alternatives like tpt_verify_saved_product or tpt_get_product. No exclusions or when-not-to-use guidance are provided, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds a meaningful scope qualifier ('local upload-ready'), but it does not explain what 'upload-ready' means or whether the list reflects some internal saved state. This is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clean, front-loaded sentence with no filler. Every word adds meaning, making it an excellent example of concise tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing tool, the description is largely sufficient. The main missing piece is the exact shape or meaning of the returned 'local upload-ready products', but with no output schema and a simple action, this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and the description introduces no ambiguous parameter-like concepts. Since there is nothing to document, the baseline for a zero-parameter tool is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') plus a resource ('local upload-ready products'), making the tool's function immediately clear. It does not explicitly contrast with siblings like tpt_get_product or tpt_product_status, but the wording is precise enough to distinguish a collection listing from a single-product or status operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'local upload-ready products' implies the tool should be used to enumerate products that are ready to be uploaded, which gives some usage context. However, the description provides no explicit guidance on when to choose this tool over sibling tools such as tpt_prepare_product or tpt_product_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutating and destructive behavior, so the description doesn't need to restate that. It adds useful behavioral context by clarifying that submission is not performed and that upload completion should be inspected afterward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no filler. The main actions lead, the non-submission clarification follows, and the post-step is given last. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool likely has a multi-step workflow with uploads, but the description omits what 'id' means, where the listing.json and files come from, prerequisites such as login, and what the caller should expect in return. Without an output schema, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'id' parameter, and the description never mentions 'id' or explains what it refers to. An agent cannot determine whether 'id' identifies the product, listing, or something else.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names specific actions (validate, fill, upload) and concrete resources (listing.json, seller fields, ZIP, PDF preview, four images). It also distinguishes itself from sibling submission workflow by explicitly saying 'Does not submit.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It conveys when to use the tool: once the listing.json is complete and before submission. The explicit 'Does not submit' provides a clear exclusion, though it doesn't name sibling alternatives such as tpt_submit_product or tpt_verify_saved_product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavior beyond annotations: it requires user authorization, mentions verified uploads and required-field review as preconditions, and warns that an 'unverified status' may result and must be reconciled before retry. This is consistent with the destructive and open-world annotations and gives the agent a clearer picture of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasting words. It front-loads the core action and then efficiently states prerequisites and a post-submission caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, open-world mutation with no output schema, the description covers prerequisites and outcome status, which is helpful. However, it does not explain what the product fields mean, what the response contains, or what 'current listing' refers to, leaving some ambiguity for an agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining parameters, but it only indirectly references authorization (authorized) and the listing context (id). It does not explain the 'active' parameter or how the id should be obtained. This is a significant gap for a tool with three undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, 'Submit', applied to 'the reviewed current listing', which clearly identifies the tool's role in the product submission workflow. It does not explicitly distinguish itself from a sibling like tpt_verify_saved_product, but 'submit' versus 'verify' is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear prerequisites: user authorization, verified completed uploads, and reviewed required fields, which tells the agent when this tool is appropriate to use. It does not explicitly name alternatives or exclusions, but the conditions imply it should be used only after preparatory steps like upload and review are done.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds a useful warning that page content is untrusted data. No side effects are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that delivers the key purpose and a relevant caution without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only inspection tool with no parameters and no output schema, the description is sufficiently complete, though it does not detail the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so no parameter documentation is needed. The zero-parameter baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the current TPT page and upload controls, making its purpose specific and distinguishable from sibling tools like tpt_list_products or tpt_get_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing current page state, but it does not explicitly say when to prefer this over sibling tools or provide alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses an important behavioral detail: credentials remain in the browser. It also implies user interaction. However, it does not elaborate on the browser session lifecycle or any potential side effects beyond opening the profile, though annotations partially cover this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with no filler or redundancy. It front-loads the core action ('Open a dedicated Chrome profile') and then adds the key privacy detail in one short follow-up sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is sufficiently complete for the tool's simple purpose. It could mention what happens after sign-in or how the session is used, but that is not essential for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is complete, so no parameter-level documentation is needed. The description adds no param detail because there is nothing to detail, matching the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a dedicated Chrome profile for user sign-in and emphasizes that credentials stay in the browser. This makes its purpose obvious and distinguishes it from the sibling product-management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this should be used when a user needs to authenticate before product operations, but it does not explicitly state when to use it versus alternatives or what precedes/follows it. Some guidance is present, but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the description does not need to repeat those. It adds useful context by noting that login is retained, which is a behavioral nuance beyond the annotations. This is a meaningful addition, not a contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It front-loads the action ('Close') and immediately provides the key side-effect (login retention), making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 is fully sufficient. It tells the agent exactly what the tool does and the critical side effect on login state. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly does not attempt to explain nonexistent parameters, and the schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Close') and a specific resource ('the dedicated browser'), and the phrase 'retaining login' clarifies the intended side effect. This distinguishes it from sibling tools like tpt_open_login and tpt_inspect, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (closing the browser after a session) but does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or exclusions. It is clear this is the counterpart to tpt_open_login, but that is not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

TPT MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![TPT MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/grahamwaters/tpt-mcp/badges/card.svg)](https://glama.ai/mcp/servers/grahamwaters/tpt-mcp)

Score Badge

Copy to your README.md:

[![TPT MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/grahamwaters/tpt-mcp/badges/score.svg)](https://glama.ai/mcp/servers/grahamwaters/tpt-mcp)