Skip to main content
Glama

Check a PHP upgrade

check_php_upgrade
Read-onlyIdempotent

Check which of the given PHP symbols are linked from the official php.net migration pages between two minor versions. Returns each hit with kind incompatible or deprecated, the version, and the page URL. A symbol that is absent was not named on those pages, which is not proof the code is safe. Send from, to, and symbols, or code instead of symbols. The span can cover at most 8 minor versions. An empty breaks list is still a successful, charged check when the pages were read. The first 5 successful calls each UTC day from one network address are free and need no key. A not_found, bad_range, or fetch_failed is not charged and does not use a free call. After the 5, send X-API-Key. A key call costs 0.04 credit only on success. Key: https://firm.bestsmartgoods.com/signup

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "from": "<from>",
      "to": "<to>"
    },
    "name": "check_php_upgrade"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesTarget minor version, newer than from, for example 8.3.
codeNoPHP source. Function calls are extracted when symbols is empty.
fromYesCurrent minor version, for example 8.1.
symbolsNoFunction or class names to look for, at most 40. Omit it and pass code instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Well beyond the annotations, it discloses the return contents, the silent-absence caveat, the 8-minor-version span cap, the billing model (5 free calls per UTC day per network address, then X-API-Key at 0.04 credit on success), and that not_found/bad_range/fetch_failed are uncharged. The annotations already cover safety, and the description layers on cost, auth, and failure semantics the agent could not otherwise know.

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?

Purpose, return shape, and the key caveat are front-loaded before the parameter and billing mechanics. The billing and signup-URL sentences are dense but each carries decision-relevant information (when a key is needed, what is charged) that an agent needs before invoking.

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?

With no output schema, the description carries the return contract and does so precisely, including the meaning of hits and the semantic of empty results. Cost, auth, error codes, and range limits are all covered, leaving nothing material unstated for a read-only lookup 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?

Schema coverage is 100%, so the baseline is 3; the description earns above that by clarifying the symbols-vs-code substitution path and by adding the 8-minor-version constraint on the from/to pair that the schema does not express. It does not add format details or the 40-symbol cap beyond what the schema already documents.

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 names a specific verb and resource: it checks whether given PHP symbols are linked from php.net migration pages between two minor versions, and it states the return shape (kind, version, page URL). It never names the siblings query_php_docs or explain_php_error, so an agent must infer why it should prefer this over a docs lookup when asking 'is this function deprecated?'.

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 gives concrete invocation guidance: send from, to, and symbols, or code instead of symbols, and the span may cover at most 8 minor versions. It also supplies an interpretation rule that shapes when to trust the answer — absence from the pages is not proof of safety. It stops short of explicit when-not-to-use or sibling routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.